Transformations between private and shared workflows

ABSTRACT

Techniques for modifying an abstraction level of a workflow are described. For example, a workflow may be analyzed to determine a first plurality of tasks, and the first plurality of tasks may then be combined into a first virtual task within an abstracted workflow. Then, the first virtual task may be linked to the first plurality of tasks, such that a virtual execution of the abstracted workflow corresponds to an actual execution of the workflow. In this way, the abstracted workflow may be shared with other parties, while a level of confidentiality associated with the workflow is preserved.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims priority to U.S. Provisional ApplicationSerial No. 60/399,455, filed on Jul. 31, 2002, and titled FLEXIBLEWORKFLOW MANAGEMENT IN CROSS-ORGANIZATIONAL ENVIRONMENTS.

TECHNICAL FIELD

[0002] This description relates to workflow management systems.

BACKGROUND

[0003] Conventional workflow systems exist which allow enterprises toformalize the processes by which the enterprises achieve their businessobjectives. Such workflow systems provide step-by-step descriptions oftasks which must or should be performed as part of the workflow, so thatindividuals or groups within the enterprise can be assigned individual(or groups of) tasks. The tasks may be dependent upon one another; forexample, a task may only be begun upon completion of a prior task(s), ortasks may be included in iterative task loops. Additionally, the tasksmay have more complex dependencies, requiring application of extensivelogic rules to ensure proper completion of the workflow.

[0004] Examples of such conventional workflows can be found explicitlyor implicitly in almost any enterprise. For example, a manufacturingplant may have a workflow for producing a particular type of good. Asanother example, an organization selling goods may have a workflow forobtaining the goods, inputting orders and/or payments for the goods,selecting a shipper for shipping the goods, and updating an inventoryrecord based on the sale.

[0005] Given that individual enterprises often have and use theirindividual workflow(s) as just described, it may be problematic for oneenterprise to interact with another enterprise, while still maintainingthe use of their respective workflows as part of the interaction(s). Forexample, a workflow associated with a first enterprise may have its ownnomenclature and/or semantics, which may be incompatible with theworkflow of a second enterprise. This is particularly true, given thatsuch workflows are often formulated completely independently of oneanother. Another difficulty facing enterprises desiring to work togetheris that workflows are often private or confidential in nature, and thebusiness(es) may be hesitant to share some or all of their privateworkflows with an external party.

[0006] As a result of these and other difficulties associated withsharing workflows between enterprises, collaborations betweenenterprises are often limited. For example, the enterprises may only beable to interact in relatively simplistic manners, so that interactionsbetween the enterprises are limited in quantity and complexity. Asanother example, the enterprises may have to resort to formulating a newworkflow to describe some or all of the tasks that are to be performedas part of the enterprises' collaboration.

SUMMARY

[0007] According to one general aspect, an abstraction level of aworkflow is modified. A workflow is analyzed to determine a firstplurality of tasks, the first plurality of tasks are combined into afirst virtual task within an abstracted workflow, and the first virtualtask is linked to the first plurality of tasks such that a virtualexecution of the abstracted workflow corresponds to an actual executionof the workflow.

[0008] Implementations may include one or more of the followingfeatures. For example, the workflow may include a second plurality oftasks, and combining the first plurality of tasks may include combiningthe second plurality of tasks into a second virtual task within theabstracted workflow. In this case, in linking the first virtual task tothe first plurality of tasks, the second virtual task may be linked tothe second plurality of tasks such that a virtual execution of theabstracted workflow corresponds to an actual execution of the workflow.

[0009] Further, in analyzing the first workflow, it may be determinedthat a last task within the first plurality of tasks precedes at mostone subsequent task within the second plurality of tasks within theworkflow. Also, analyzing the workflow may include determining that nointernal task within the first plurality of tasks, exclusive of the lasttask, immediately precedes an external task that is not included withinthe first plurality of tasks. Alternatively, analyzing the workflow mayinclude determining that no internal task within the first plurality oftasks, exclusive of a first task of the first plurality of tasks,immediately succeeds an external task that is not included within thefirst plurality of tasks.

[0010] Also in analyzing the workflow may include determining whether aplurality of conditions are met, and determining whether the pluralityof conditions are met may include inputting a selected task from thefirst plurality of tasks, the selected task being a first task of thefirst plurality of tasks, considering each succeeding task of theselected task until a last task of the first plurality of tasks isreached (wherein the last task precedes at most one subsequent taskwithin the second plurality of tasks within the workflow), determiningthat no internal task within the first plurality of tasks, exclusive ofthe last task, immediately precedes an external task that is notincluded within the first plurality of tasks, and determining that nointernal task within the first plurality of tasks, exclusive of thefirst task, immediately succeeds an external task that is not includedwithin the first plurality of tasks.

[0011] In this case, it may be determined that the plurality ofconditions are not met, a preceding task outside of the first pluralityof tasks and preceding the first plurality of tasks within the workflowmay be considered (the preceding task immediately preceding at least afirst pair of tasks). The last task within the first plurality of tasksmay be determined to be immediately preceded by at least a second pairof tasks, and a modified first plurality of tasks may be defined thatincludes the preceding task, the last task, and all intervening tasks.In combining the first plurality of tasks, the modified first pluralityof tasks may be combined into the first virtual task within theabstracted workflow.

[0012] Analyzing the workflow may include selecting all task subsets ofthe workflow which, when used as the first plurality of tasks, allow thelinking of the first virtual task to the first plurality of tasks. Also,analyzing the workflow may include inputting a selected task from amongthe workflow, and determining a first subset of tasks inclusivelypreceding the selected task which, when used as the first plurality oftasks, allow the linking of the first virtual task to the firstplurality of tasks. In the latter case, a second subset of tasksinclusively succeeding the selected task may be determined which, whenused as the first plurality of tasks, allow the linking of the firstvirtual task to the first plurality of tasks.

[0013] Analyzing the workflow may include expressing actual tasks withinthe first plurality of tasks as first vertices within a first matrix,wherein values of the first vertices within the first matrix may bedetermined by actual dependencies between the tasks within the firstplurality of tasks, and wherein combining the first plurality of tasksinto a first virtual task includes expressing virtual tasks within theabstracted workflow as second vertices within a second matrix, whereinvalues of the second vertices within the second matrix may be determinedby virtual dependencies between the virtual tasks within the abstractedworkflow.

[0014] In this case, linking the first virtual task to the firstplurality of tasks may include replacing a selected plurality of thefirst vertices with a selected one of the second vertices, or replacinga selected one of the second vertices with a selected plurality of thefirst vertices.

[0015] The first plurality of tasks within the workflow may beconfidential tasks associated with a first party, wherein the abstractedworkflow permits communications regarding the confidential tasks withoutdivulging the confidential nature of the confidential tasks.

[0016] According to another general aspect, an apparatus includes astorage medium having instructions stored thereon. The instructionsinclude a first code segment for grouping a task subset from a pluralityof tasks comprising a workflow, a second code segment for constructing avirtual workflow including a first virtual task, and a third codesegment for associating the task subset with the first virtual task byrequiring that completion of the task subset corresponds to completionof the first virtual task.

[0017] Implementations may include one or more of the followingfeatures. For example, the task subset may include confidential tasksassociated with a first party, and the virtual workflow may permitcommunications regarding the confidential tasks without divulging theconfidential nature of the confidential tasks. The first code segmentmay include a fourth code segment for selecting all task groupings ofthe workflow which, when used as the task subset, allow the third codesegment to associate the task subset with the first virtual task.

[0018] The first code segment may include a fourth code segment forinputting a selected task from among the workflow, and a fifth codesegment for determining a first grouping of tasks inclusively precedingthe selected task which, when used as the task subset, allow the thirdcode segment to associate the first virtual task with the task subset.In this case, a sixth code segment may included for determining a secondgrouping of tasks inclusively succeeding the selected task which, whenused as the task subset, allow the linking of the first virtual task tothe task subset.

[0019] The first code segment may include a fourth code segment forexpressing actual tasks within the task subset as first vertices withina first matrix, wherein values of the first vertices within the firstmatrix may be determined by actual dependencies between the tasks withinthe task subset, and the third code segment may include a fifth codesegment for expressing the first virtual task within the virtualworkflow as second vertices within a second matrix, wherein values ofthe second vertices within the second matrix may be determined byvirtual dependencies between the virtual tasks within the virtualworkflow.

[0020] In this case, the third code segment may include a sixth codesegment for replacing a selected plurality of the first vertices with aselected one of the second vertices, or for replacing a selected one ofthe second vertices with a selected plurality of the first vertices.

[0021] The third code segment may include a fourth code segment forensuring that a final task of the task subset immediately precedes nomore than one subsequent task of a remaining plurality of tasks withinthe workflow. The third code segment may include a fourth code segmentfor ensuring that no task of the task subset, other than a final task ofthe task subset, immediately precedes an external task that is externalto the task subset and included within the workflow. The third codesegment may include a fourth code segment for ensuring that no task ofthe task subset, other than a first task of the task subset, immediatelysucceeds an external task that is external to the task subset andincluded within the workflow.

[0022] According to another general aspect, a workflow model includes aworkflow comprising a first task and a second task, a workflow viewcorresponding to the workflow and comprising a first virtual task, afirst dependency between a first execution of the first task and avirtual execution of the first virtual task, and a second dependencybetween a second execution of the second task and the virtual executionof the first virtual task.

[0023] Implementations may include one or more of the followingfeatures. For example, the first dependency and the second dependencymay communicate execution state information about the first and secondtask, respectively, to the first virtual task. The first dependency andthe second dependency may ensure that an actual completion of the firstand second task may be reflected as a completion of the first virtualtask.

[0024] The first task may be confidential to an owner of the workflow,and the workflow view may allow communications between the owner and asecond party which protect the confidentiality of the first task. Inthis case, the communications may include a collaborative workflowbetween the owner and the second party, wherein the collaborativeworkflow includes the workflow view.

[0025] The details of one or more implementations are set forth in theaccompanying drawings and the description below. Other features will beapparent from the description and drawings, and from the claims.

DESCRIPTION OF DRAWINGS

[0026]FIG. 1 is an illustration of a three-tiered workflow model.

[0027]FIG. 2 is an illustration of an example of the three-tieredworkflow model of FIG. 1 for implementing a manufacturing process.

[0028]FIG. 3 is an illustration of a more generic example of thethree-tiered workflow model of FIG. 2.

[0029]FIG. 4 is a diagram of an architecture for implementing athree-tier workflow model.

[0030]FIG. 5 is a Petri-Net representation of state and eventinformation related to a workflow task.

[0031]FIG. 6 is a Petri-Net representation illustrating state and eventinformation for two successive tasks in a workflow, relative to theirworkflow view task.

[0032]FIG. 7 is a Petri-Net representation illustrating state and eventinformation for a workflow view task in a workflow view, relative to itsprivate tasks.

[0033]FIG. 8 is a block diagram of a task illustrating the task inputsand outputs types of relevant data.

[0034]FIG. 9 is a block diagram of an eService.

[0035]FIG. 10 is a diagram illustrating operations for modifying one ormore workflows.

[0036]FIG. 11 is a digraph representing a workflow.

[0037]FIG. 12 is an illustration of a matrix used as a specializationoperator.

[0038]FIG. 13 is a matrix illustrating an algorithm for computingspecialization.

[0039]FIG. 14 is an illustration of a matrix used as a generalizationoperator.

[0040]FIG. 15 is a matrix illustrating an algorithm for computinggeneralization.

[0041]FIG. 16 is an illustration of a matrix used as a verticalizationoperator.

[0042]FIG. 17 is a block diagram illustrating a classification schemefor classifying workflow groups.

[0043] FIGS. 18-23 provide further examples of how a workflow can beverticalized (generalized).

[0044]FIG. 24 is a flowchart describing an algorithm to computev-structures.

[0045]FIG. 25 is a flowchart for finding valid v-structures.

[0046]FIG. 26 is a flowchart for finding v-structures which is a back-upto the flowchart of FIG. 25.

[0047]FIG. 27A is a first example of a digraph (workflow) 2700.

[0048]FIG. 27B is a table listing adjacent v-structures for each vertex(node) of the digraph of FIG. 27A.

[0049]FIG. 28A is a first example of a digraph (workflow).

[0050]FIG. 28B is a table listing adjacent v-structures for each vertex(node) of the digraph of FIG. 28A.

[0051]FIG. 29 is a first screenshot of a tool for identifyingv-structures.

[0052]FIG. 30 is a second screenshot of a tool for identifyingv-structures.

[0053]FIG. 31 is a third screenshot of a tool for identifyingv-structures.

[0054]FIG. 32 is a fourth screenshot of a tool for identifyingv-structures.

[0055]FIG. 33 is a block diagram of an outsourced workflow.

[0056]FIG. 34 is a block diagram of a distributed workflow.

[0057]FIG. 35 is an expanded block diagram of the distributed workflow.

[0058]FIG. 36 is a block diagram of a parallel combination of multipleworkflows.

[0059]FIG. 37 is a combination workflow including synchronizing tasks.

[0060]FIG. 38 is an example of a first matrix resulting from a firstexpansion operation.

[0061]FIG. 39 is an example of a second matrix resulting from a secondexpansion operation.

[0062]FIG. 40 is an example of a third matrix resulting from a thirdexpansion operation.

[0063]FIG. 41 is an example of a fourth matrix resulting from a fourthexpansion operation.

[0064] FIGS. 42A-42D are digraphs illustrating valid and invalid resultsof a reduction operation.

[0065]FIG. 43 is a matrix that is an example of a reduction operator.

[0066]FIG. 44 is a block diagram of three aspects of workflowinteroperability.

[0067]FIG. 45 is a block diagram of a corporate procurement process(CPP).

[0068]FIG. 46 is a block diagram of a collaborative workflow.

[0069]FIG. 47 is a block diagram of a workflow management system.

[0070]FIG. 48 is an illustration of a more generic example of thethree-tiered workflow model of FIG. 2.

[0071]FIG. 49 is an illustration of an aggregate workflow.

[0072]FIG. 50 is a flowchart illustrating techniques for changing astate of a task within a workflow.

[0073]FIG. 51 is a flowchart illustrating techniques for changing astate of a workflow view task within a workflow view.

[0074]FIG. 52 is a flowchart for aggregating a workflow view and aworkflow into an aggregated workflow.

[0075]FIG. 53 is a flowchart for inserting aggregation routing tasksinto the aggregate workflow of FIG. 52.

DETAILED DESCRIPTION

[0076] In the following description, Section I describes a three-levelmodel for allowing enterprises to fully and easily collaborate with oneanother, while still taking advantage of the enterprises' individual,existing workflows and ensuring confidentiality of tasks within theworkflows on an as-needed basis. The three-level or three-tier modelinvolves, on the first level, a first private workflow associated with afirst enterprise, and a second private workflow associated with a secondenterprise. On the second level, each of the private workflows isabstracted, such that a first virtual workflow having a first set ofvirtual tasks is generated which corresponds to the first privateworkflow, while a second virtual workflow having a second set of virtualtasks is generated which corresponds to the second private workflow.Finally, at the third level, a collaboration workflow is generated fromthe two virtual workflows. The virtual workflows have state dependencieswith respect to their respective private workflows, such that acompletion of a virtual task definitively corresponds to a completion ofa corresponding actual task(s) within the private workflow.

[0077] Section II describes techniques for determining whether anabstraction level of a workflow can be legitimately altered in a desiredmanner, and for, if allowed, actually performing the alteration. Forexample, a private task or group of tasks within an enterprise'sexisting workflow may be abstracted, or generalized, into one or morevirtual tasks. Conversely, a virtual task may have its abstraction levelreduced, or specialized, into one or more private tasks. Thesetechniques for determining a feasibility of altering an abstractionlevel of a workflow, and for performing the alterations, can be utilizedfor various purposes, including implementation of the three-tiercollaborative workflow model described in Section I.

[0078] Section III describes techniques for combining, or expanding,multiple workflows into a single workflow, while maintaining a validityof both the individual and joined workflows. Conversely, techniques arealso described for dividing, or reducing, a single workflow into aplurality of individual workflows, where the individual workflows may beperformed by individual parties or enterprises. These techniques can beused for a variety of purposes, including implementation of thethree-tier workflow model of Section I.

[0079] Section IV describes why the three-tier model is necessary and/oruseful for performing collaborative workflows, along with examples ofsuch collaborative workflows.

[0080] Section V describes techniques for executing the three-tier modelwithin, or in association with, a workflow engine. More specifically,Section V describes techniques for effectively supporting concurrentexecution of an actual workflow and its associated workflow view.

Section I

[0081]FIG. 1 is an illustration of a three-tiered workflow model 100. InFIG. 1, a first tier of the three-tiered workflow model is a partner orprivate tier 102. Private tier 102 includes a first private workflow 104associated with a first entity such as an enterprise, a second privateworkflow 106 associated with a second entity, and a third privateworkflow 108 associated with a third entity. In FIG. 1, each workflow(e.g., 104, 106, 108) includes various tasks having various dependenciestherebetween, and each of the tasks represents an actual task to beperformed by, for example, an employee of the appropriate entity.

[0082] A second tier of the three-tiered workflow model is an abstractedor virtual or “workflow view” tier 110. Workflow view tier 110 includesabstracted versions of the private workflows 104, 106, and 108. Moreparticularly, the workflow view tier 110 includes a workflow view 112abstracted from the private workflow 104, another workflow view 114abstracted from the private workflow 106, another workflow view 116 thatis also abstracted from the private workflow 106, and a final workflowview 118 which is abstracted from private workflow 108. As explained inmore detail below, a given private workflow may have a plurality ofabstractions or workflow views which can be generated therefrom, asshown by the example of workflow views 114 and 116, which, althoughdifferent, are both generated from the same private workflow 106. Thisallows different partners to have different views of the same underlyingworkflow.

[0083] Specific techniques for generating the abstracted workflow views112, 114, 116, and 118 (and for (re-)obtaining the private or partnerworkflows 104, 106, and 108 therefrom) are discussed in more detail inSection II. For the purposes of this section, however, it is assumedonly that the workflow views are generated by some technique, which maybe fully or partially automated, or may be simply performed bytrial-and-error.

[0084] The third tier of the workflow model of FIG. 1 includes acoalition workflow tier 120. The coalition workflow tier 120 includes,in FIG. 1, two coalition workflows which represent the combination ofparticular workflow views. More specifically, the coalition workflowtier 120 includes a first coalition workflow 122 (also identified as“Coalition B” in FIG. 1) which represents a combination of the workflowview 112 and the workflow view 114. Similarly, the coalition workflowtier 120 also includes another coalition workflow 124 (also identifiedas “Coalition A” in FIG. 1), which represents a combination of theworkflow views 116 and 118.

[0085] Specific techniques for combining the various workflow views intotheir corresponding coalition workflows (and for (re-)obtaining theindividual workflow views from the coalition workflows) are discussedbelow in Section III. For the purposes of this Section, however, it isassumed only that the coalition workflows are generated by sometechnique, which may be fully or partially automated, or which maymerely include trial-and-error.

[0086] The three-tiered approach of FIG. 1 is essentially a logicalintegration of all data and workflows needed by an application into onelogical workflow management system, which may also be referred to as the“unified approach.” It implies the existence of a unified meta-modelwhich is able to map different existing models. Such integration createsthe illusion of a single workflow management system, and hides from theuser and the application the intricacies of different workflowmanagement systems and different access methods. It provides users andapplications with uniform access to workflows contained in variousworkflow management systems without migrating the workflows to a newworkflow management system, without requiring the users and applicationsto know either the location or the characteristics of different workflowmanagement systems.

[0087]FIG. 2 is an illustration of an example of the three-tieredworkflow model of FIG. 1 for implementing a manufacturing process. InFIG. 2, a company B 202 confirms their upcoming production of a goodwith a company A 204. Company B 202 is responsible to produce aparticular set of widgets (widgets 1, 2, 3, and 4) that are required ina production process of company A 204. Company B 202 has an internal (orprivate or partner) workflow K 206, which corresponds in concept to oneof the partner workflows 104, 106, or 108 of FIG. 1. The partnerworkflow K 206 has a corresponding workflow view L 208, whichcorresponds in concept to one of the workflow views 112, 114, 116, or118 of FIG. 1. Similarly, an internal workflow O 210 of company A 204 isabstracted as a workflow view P 212.

[0088] In the production process of FIG. 2, then, a collaboration ofworkflow view L 208 and workflow view P 212 provide a collaborationworkflow corresponding in concept to coalition workflows 122 and 124 ofFIG. 1. In FIG. 2, this collaboration occurs in a peer-to-peer manner,and the coalition workflow is not explicitly shown as a separateworkflow, as discussed in more detail with respect to FIG. 3 below.

[0089] In FIG. 2, the company B 202 starts its workflow K 206 with aplan production task 214 according to its routine schedule. Oncemanagement has verified the availability of resources in an approvaltask 216, then an abstracted view of the two tasks 214 and 216, i.e., aproduction planning virtual task 218 within workflow L 208, is alsoconsidered to be completed.

[0090] At this point, a notification 220 is sent to company A 204, whichstarts a verification task 222, which actually involves company A 204checking an availability of its production line in task 224, andgenerating an approval for company B 202 in approval task 226.

[0091] Company A 204 then sends a response to company B 202 in responsetask 228, which is received by company B 202 in a check response task230. At this point, company B begins a virtual production task 232,which includes a splitting task 234 which conditionally splits theproduction process into a first widget-producing task 236 and a secondwidget-producing task 238, or into a third-widget producing task 240 anda fourth widget-producing task 242. Completion of a joining task 244 forjoining the widgets then completes the virtual production task 232.

[0092] At the same time that company B 202 is performing the productiontask 232, company A 204 begins its own production task 246, whichincludes an assembly task 248 and a delivery task 250 for delivery to adifferent production line inside company A 204.

[0093] Once company B 202 finishes its production task 232, it assemblesthe widgets that have been produced in an assembly task 252, anddelivers them in a delivery task 254, which completes a workflow viewdelivery task 256. Company A 204 then performs a workflow view task 258,and assembles the master product in an assembly task 260, whichcorresponds to an actual assembly task 262 and an actual quality controltask 264.

[0094]FIG. 3 is an illustration of a more generic example of thethree-tiered workflow model of FIG. 2. In FIG. 3, as in FIG. 2, companyB 202 has a private workflow K 302 and a corresponding workflow view L304. Similarly, company A 204 has a private workflow O 306 and aworkflow view P 308.

[0095] Private workflow K 302 includes a first task 310, a second task312, a third task 314, a fourth task 316, a fifth task 318, a sixth task320, a seventh task 322, an eighth task 324, a ninth task 326, and atenth task 328. The first task 310 and the second task 312 are groupedinto a first abstracted task 330 within workflow L 304. The third-eighth(314-324) tasks are grouped into a second abstracted task 332 withinworkflow L 304, and the ninth task 326 and the tenth task 328 aregrouped into a third abstracted task 334 within workflow L 304.

[0096] Private workflow O 306 includes a first task 336, a second task338, a third task 340, a fourth task 342, a fifth task 344, and a sixthtask 346. The first task 336 and the second task 338 are grouped into afirst abstracted task 348 within workflow P 308. The third task 340 andthe fourth task 342 are grouped into a second abstracted task 350 withinworkflow P 308, and the fifth task 344 and the sixth task 346 aregrouped into a third abstracted task 352 within workflow P 308.

[0097] In FIG. 3, the various workflows may be similar in operation tothose shown in FIG. 2. In FIG. 3, however, it is shown explicitly that acollaboration of companies B 202 and A 204 may be expressed as acoalition workflow M 354. In FIG. 3, coalition workflow M 354 is shownto contain a first collaborative task 356, a second collaborative task358, a fourth collaborative task 360 (a splitting task), a fourthcollaborative task 362, a fifth collaborative task 364, a sixthcollaborative task 366 (a joining task), and a seventh collaborativetask 368. Workflow M 310 may be implemented in a peer-to-peer manner asin FIG. 2, or may be implemented by, or with the help of, a mediatingparty, as discussed in more detail below.

[0098] Thus, In FIG. 3, there are six view-activities 330, 332, 334 (inworkflow view L 304), and 348, 350, and 352 (in workflow view P 308).The rules for describing how the workflow view activities are tointeract are expressed though the coalition workflow M 354, with itsactivities 356, 358, 362, 364, and 368. The reason that there are atotal of six view-activities and only five coalition activities is thatone view activity is only intended for monitoring purposes.

[0099] As shown in FIGS. 2 and 3, each workflow view task in a workflowview corresponds to one or more actual tasks in a partner workflow.Thus, the workflow view(s) provide for monitoring of their correspondingpartner view(s), and an assurance that the partner views are in factbeing executed. As discussed in more detail below, this ability may beadvantageous over an approach of merely indicating that an interactionbetween workflows has occurred, or will occur.

[0100] An analogous way of considering the correlation(s) betweenworkflow views and their corresponding private workflows is to considerthe tasks of each in terms of their execution states. In general terms,state changes in one of the actual tasks are required to be made visibleto the corresponding virtual task, and vice-versa, as discussed in moredetail below.

[0101]FIG. 4 is a diagram of an architecture 400 for implementing athree-tier workflow model. In FIG. 4, a first workflow management system402 includes a variety of elements designed to perform at least thefollowing tasks: implementation of an actual (private) workflow,generation of workflow views (i.e., abstracted or virtual workflows)from the private workflows, and collaboration with an external partysuch as another workflow management system or workflow mediator tosecurely implement a coalition workflow.

[0102] More specifically, the first workflow management system 402includes a private workflow modeler 404, which supports the lifecycle ofprivate workflow models implemented by the workflow management system402, such as workflows 206, 210, 302, and 306 in FIGS. 2 and 3.

[0103] A view modeler 406 is utilized to generate and manipulateworkflow views that are abstracted or virtual versions of the actualworkflows, such as workflow views 208, 212, 304, and 308 in FIGS. 2 and3. The view modeler 406 may operate automatically, based on availabledata, and/or through interaction with a user. Specific techniques forimplementing the view modeler 406 are discussed below in Sections II andIII.

[0104] A monitor 408 assists in tracking the execution of privateworkflows, workflow views, and coalition workflows with respect to oneanother. Functionality of the monitor 408 is discussed in more detailbelow.

[0105] A workflow engine 410 is operable to actually execute the privateworkflows modeled by the private workflow modeler 404, and to mapworkflow view states to private workflow states and/or workflow data, asdiscussed in more detail below. The workflow engine 410 providesrelevant information and allows access to workflow views, such that theviews can interact with entities outside of the workflow managementsystem 402 as described below. In other words, the workflow engine 410executes private workflows internally, and also virtually executesworkflow views and ensures the appropriate interdependencies between thetwo types of workflows.

[0106] A user agent 412 is a human user's interface to the workflowsystem 402. The user agent 412 can be, for example, a task list. Anapplication conduit 414 allows the workflow management system 402 tointerface with external applications, such as back-office applicationslike customer relationship management systems, supply chain management,and vending machines, as well as front-office applications, such as aword processor or spreadsheets. Application Conduits 414, generallyspeaking, extend the reach of workflow management systems to collect anddisseminate relevant data.

[0107] A private workflow and workflow view repository 416 stores andmanages workflow and workflow view models and instances, as well as therelationships between the private workflows/workflow views andmodels/instances of models.

[0108] A gateway 418 provides a company's process interface to theoutside world. It redirects all ingoing and outgoing process requests,serving as a proxy. It hides internal systems from the outer world, andallows the participation of non process-oriented systems in businessprocesses. The gateway 418 also serves as a firewall against unwantedintrusions, and provides transparent routing services to externalparties with respect to the workflow management system 402. The gateway418 may also be used to convert outgoing message objects from a formatused by the internal system 402 to a format that can be understood by anexternal recipient. The gateway 418 can provide a full log of allservices that have been invoked on the systems of an organization.

[0109] A security manager 420 handles all security-related aspects ofcommunication for the workflow management system 402. It decryptsincoming messages, and verifies the sender's identity in cooperationwith a Certificate Authority 422, using a security technique such asPublic Key Infrastructure (“PKI”). In the case of implementing PKI, thesecurity manager 420 may also encrypt outgoing messages with therecipient's public key.

[0110] In FIG. 4, a mediator 424 interacts with the first workflowmanagement system 402 and a second workflow management system 426 toimplement a coalition workflow. However, as discussed above with respectto FIGS. 2 and 3, and discussed in more detail below, the workflowmanagement system 402 and 426 may also interact directly, in apeer-to-peer environment. In the second workflow management system 426,it should be understood that the elements associated therewith, i.e., aprivate workflow modeler 428, a view modeler 430, a monitor 432, anengine 434, a user agent 436, an application conduit(s) 438, a privateworkflow and workflow view repository 440, a security manager 442, and agateway 444 all provide functionality corresponding to theirsimilarly-named elements within the first workflow management system402.

[0111] In the mediator 424, a monitor 446 is available for interactingwith the monitor 408 and the monitor 432. It should be understood thatan availability of monitoring functionality for a particular workflowlayer within the three-tier model is determined by the availability ofinformation from the relevant workflow engine. Thus, a workflow monitor(such as monitor 446) that belongs to a coalition will be able to trackworkflows on the public (coalition) and workflow view layer, whilst aworkflow monitor (such as monitor 408 or 432) inside a partner companywill, in addition, track the company's respective private workflows andtheir state transitions.

[0112] An eServices Repository 448 is an entity of the mediator 424. Itis a catalogue of available eServices and their particularcharacteristics that are available to the mediator. Generally speaking,eServices are services that can be provided to customers by providerswho specialize in those particular services. Such eService are discussedin more detail below, and are particularly useful in the architecture ofFIG. 4, in which a particular service may be repetitively required byone or more companies within the coalition workflow.

[0113] An instance repository 450 persistently stores information abouta current state of execution of coalition workflows. This functionalityallows monitoring and exception handling; for example, when one of thecommunication partners has not received a message and the message needsto be re-sent.

[0114] In a mediated environment such as that of FIG. 4, the workflowmonitor 446 will be able to query state information about other workflowview instances from the instance repository 450. In a non-mediatedenvironment, in contrast, the workflow monitor 446 is required tocollect workflow view instance data from the partners' workflowmanagement systems in order to represent the state of coalition workflowinstance.

[0115] A message queue 452 can be considered to be a mailbox that actsin close cooperation with the instance repository 450. Specifically, itstores messages for communication partners, thereby supporting offlinescenarios.

[0116] Finally with respect to the mediator 446, a security manager 454interacts with the security managers 420 and 442, and the certificateauthority 422, to ensure secure communications between the mediator 424and the workflow management systems 402 and 426.

[0117] The architecture 400 of FIG. 4 does not reference or require aparticular communication protocol or technology. It may be advantageous,however, to utilize a protocol that is sufficiently expressive to allowfor the modelling of messages that result in creation of workflowinstances from existing workflow models, and support interaction ofworkflow instances during their lifecycles. These requirements are beingsupported by, for example, a workflow Extensible Mark-up Language(“XML”) specification developed by the Workflow Management Coalition(“WFMC”) and described in the WFMC Technical Report WFMC-TC-1023,“Workflow standard-interoperability-wf-xml binding version 1.1,” 2001.

[0118] Exemplary techniques for utilizing the architecture 400 of FIG. 4involve the partners in a coalition agreeing on a particular goal toachieve for modeling in a coalition workflow. Partners may choose thosetasks of the coalition workflow that they want to implement by theirprivate systems 402 and 426. Each partner will apply a method such asthe method of reduction, discussed below in Section III, to thecoalition workflow, in order to understand the required relationships ofthe partner's tasks in the context of the coalition.

[0119] Each partner may then either develop new private workflows, usingthe method of specialization (discussed in Section II), or re-useexisting workflows and connect them with their workflow views throughgeneralization (also discussed in Section II). Once each partner hasbuilt their respective workflow views, they may apply the method ofexpansion (discussed in Section III) on the basis of the coalitionworkflow definition, in order to add the required synchronizing tasks(e.g., AND-splits and ANDjoins) to their workflow views. Thesemodifications are then propagated back to the view's definition in theprivate workflow & workflow view repository 416 and 440.

[0120] The instantiation of a collaborative workflow may be triggered byeither an external event to a workflow view or by the request of one ofthe partners to their private workflow management system 402, 426.Through the execution, state dependencies between workflow view andcorresponding private workflow are updated when changes to states occur,as discussed in more detail below with respect to FIGS. 5-7. Eventually,one private engine, such as engine 410, will start executing a privateworkflow. Once communication with a partner is required, the gateway 418will request the security manager 420 to encrypt the message and send itoff to the recipient. In a mediated environment such as in FIG. 4, themediator 424 will decrypt the message with the mediator's private key,encrypt it with the recipient's public key, store it and put it in themessage queue 452, and inform the appropriate participant about the newmessage.

[0121] Once the recipient has pulled the message from the message queue452, the recipient decrypts the message with their own private key andsends the message to the engine 434. The engine 434 takes appropriateaction by, for example, starting a new private workflow, or forwardingthe message to an already running instance.

[0122] The communication partners should be able to identifyalready-instantiated workflow views in a target workflow managementsystem. For example, a token may be passed along the communication chainthat identifies the instance and the type of a coalition workflow. Theinvolved workflow management systems 402, 426 are thus able toinstantiate their private workflow objects, and assign them to workflowview objects that participate in the coalition workflow. The coalitionworkflow instance identifier is assigned to these objects.

[0123] Thus, the architecture 400 for implementing the three-tieredworkflow model of FIGS. 1-3 provides for flexible, robust and secureinteractions between the coalition partners. Workflow views are exposedas interaction points, which can be used to form a collaborativeworkflow. The inter-enterprise coordination thus builds on a distributedbusiness process model where every partner manages their own part of theoverall business process.

[0124] Returning to FIGS. 2 and 3, the discussion below describestechniques for joining workflow views into a collaboration workflowusing “control flow dependencies,” and for joining private workflows toworkflow views using “state dependencies.” In the following discussion,it is assumed that the private workflows 302 and 306 should remainprivate and confidential, and remain unchanged.

[0125] A control flow dependency, generally speaking, expresses how twoor more workflows can interact, through the introduction ofsynchronizing tasks and/or dependencies. In this approach, aclosed-state of a preceding task is connected to an open-state of thefollowing tasks. Route tasks, such as joins and splits, coordinate thecontrol flows of the involved workflows to ensure order preservation ofthe overall workflow that results from the interaction of the individualworkflows. For example, an “AND-split” task splits a process flow intotwo flows, where each of the flows must be performed before they can berejoined at an “AND-join” task. Similarly, an exclusive “OR-split” tasksplits a process flow into two flows, where only one of the flows mustbe performed before the flows are rejoined at an exclusive “OR-join”task and allows to proceed.

[0126] Control flow dependencies provide a loose coupling betweenworkflows, because they merely pass on a state and workflow-relevantdata from one workflow to another once it closes. FIG. 2 providesexamples of control flow dependencies, specifically, tasks 220 and 228can be considered to be “splitting tasks” (i.e., AND splits) while tasks230 and 258 can be considered to be “joining tasks” (i.e., AND joins).These tasks, as shown in FIG. 2, augment the workflow view tasks 218,232, 256, 222, 246, and 260.

[0127] State dependencies, in contrast to control flow dependencies,provide a very tight coupling between tasks. For example, statedependencies between a workflow view and its associated workflow tasksassure that the workflow view always accurately represents the state ofits corresponding private workflow tasks, and that any valid messagesthat are sent to the workflow view by a third entity are forwarded tothe appropriate task in the corresponding private workflow.

[0128]FIG. 5 is a Petri-Net representation of state and eventinformation related to a workflow task. In FIG. 5, a circle representsstate, while a square represents an event.

[0129] In FIG. 5, there is shown an open.notRunning.notStarted(“not_started”) state 502, indicating that the task has been created,but was not started yet. This state may lead to a run event (command)504, which in turn may lead to an open.running (“running”) state 506, inwhich the task is executing.

[0130] The not_started state 502 may also lead to a terminate event 508,in which a user commands termination of enactment of the task, whichleads to closed.terminated (“terminated”) state 510, in which enactmentof the task is actually terminated. Somewhat similarly, The not_startedstate 502 may also lead to an abort event 512, in which an applicationis aborted, which leads to closed.aborted (“aborted”) state 514, inwhich enactment of the task is actually aborted.

[0131] The running state 506 may lead to a suspend event 516, whichleads to a state of temporary suspension of execution referred to asopen.notRunning.suspended (“suspended”) 518. The running state 506 mayalso lead to a completion event (“complete”) 520, which in turn leads toa completed state 522.

[0132] In FIG. 5, every state of a task belongs to one of the followinggroups: (1) open: the task is being enacted, where the state “open” hassubgroups (1a) running: the task is being executed, and (1b) notRunning:the task is temporarily not executing, and the state “notRunning” hasthe further subgroups (1bI) notStarted: the task has not been startedyet, and (1bII) suspended: the task is temporarily not being executed;and (2) closed: enactment of the task has been finished, where the state“closed” has the subgroups (2a) aborted: enactment of the task has beenaborted by a user, (2b) completed: enactment of the task has completednormally, and (2c) terminated: the task has been aborted by the system.

[0133] In the following discussion, the function “change-state” (“cs”)is a function of a task t, and requests t to change from its currentstate s0 into a new state s1, denoted as: cs(s1) t. The state transitionfrom s0 to s1 is denoted as s0→s1.

[0134] Considering FIG. 3, the workflow K 302 includes the first task k1310 and the second task k2 312. The workflow view (virtual or abstractedworkflow) L 304 has corresponding task 330. In the discussion below,tasks k 310, 312 within workflow K 302 generically represent privateworkflow tasks within a private workflow, and task 1 330 genericallyrepresents workflow view tasks within a workflow view.

[0135] Thus, when task l1 requests cs(s1) k1, task k1 310 performs thefollowing assessment. First, task k1 310 determines whether the statetransition s0→s1 is valid, i.e. whether it is reflected by the adjacentstate transition model (as depicted in FIG. 5) of task k1 310. If so,then task k1 310 determines whether all operational resources areavailable; i.e., whether all required private dependencies are active(or, in the case where task k1 310 is the first task in workflow K 302,whether the local workflow engine 410, 434 is ready to instantiateworkflow K 302). If so, task k1 310 performs the state transition s0→s1.In this case, s1 is now the state of task k1 310.

[0136] Similarly, task l1 330 performs the following assessment uponreceiving from task k1 310 a request for cs(s1) 11. First, task l1 330determines whether the state transition s0→s1 is valid. If so, task l1330 determines whether all operational resources are available; i.e.,whether all required virtual dependencies are active (unless task l1 330is the first task in workflow view L 304). If so, task l1 330 performsthe state transition s0→s1, so that s1 becomes the state of 11.

[0137] One approach to performing state mapping is to map between statesof task(s) to the state of the corresponding virtual task, and viceversa, as shown in Table 1: TABLE 1 Virtual Task Tasks open.running oneopen.running AND none (closed.aborted OR closed.terminated)one.notRunning one open.notRunning AND none closedopen.notRunning.notStarted first task open.notRunning.notStartedopen.notRunning.suspended one open.notRunning.suspended AND none(open.running OR closed.aborted OR closed.terminated) closed.aborted oneclosed.aborted closed.terminated one closed.terminated closed.completedlast task and all others that have been instantiated have beenclosed.completed

[0138] However, such an approach may be unable to capture all thesemantics of a workflow. For example, there may be a situation in whichtwo tasks are being executed in parallel (e.g., task k4 316 and task 318k5 in FIG. 3 if task k3 314 was AND-split and task k8 324 was anAND-join), and one of them aborts (i.e., enters the state closed.aborted514). In this case, aborting one task does not mean that itscorresponding virtual task must abort as well. This is in contradictionto when a virtual task receives a request to enter into a particularstate, particularly open.notRunning.suspended, closed.aborted, orclosed.terminated. In these cases, all corresponding private taskinstances have to enter the respective states of:open.notRunning.suspended, closed.aborted, and closed.terminated,according to the individual state transition model.

[0139] Therefore, another approach to state mapping is to explicitly andindividually model relationships between virtual and private taskstates, while also providing a default in the case of absence of anexplicit correlation as suggested in Table 1. This approach adds a layerof flexibility and practicality for dealing with real-world workflows,and allows accurate messaging between a private task and its workflowview task, including when the message(s) originate from an externalparty (i.e., a member of the coalition).

[0140]FIG. 6 is a Petri-Net representation illustrating state and eventinformation for two successive tasks in a workflow, relative to theirworkflow view task. The workflow might be, for example, the workflow K302 in FIG. 3, and the tasks might be task k1 310 and task k2 312. Theworkflow view (virtual or abstracted) task would then be task l1 330within workflow view L 304.

[0141]FIG. 7 is a Petri-Net representation illustrating state and eventinformation for a workflow view task in a workflow view, relative to itsprivate tasks. For example, the workflow view task might be task l1 330,and the private tasks might be task k1 310 and task k2 312.

[0142] Generally speaking, as described above, state dependenciesexpress that individual tasks in workflow K 302 and workflow view L 304should not change their state(s), unless such a state change satisfiesrules that describe how states in the two workflows relate.

[0143] In FIG. 6, when task k1 310 or task k2 312 enters a state, itnotifies task l1 330, and vice versa. Also, each state in workflow viewL 304 has a corresponding “tentative state,” denoted in FIGS. 6 and 7 as“tstate,” such as, for example, “task l1 tRun.” These tentative statesallow task l1 330 to revert to the original state in which it was beforeit received an event, in case task k1 310 and/or task k2 312 are unableto execute a particular state change request.

[0144] In FIGS. 6 and 7, it is assumed that task k1 310 and task l1 330are initially in a state not_Started 602 and 702, respectively. Also,messages that originate from task l1 330 are prefixed with “l1” whenreferred to in task k1 310 and task k2 312, whereas messages thatoriginate from task k1 310 or task k2 312 are prefixed with “k1” or“k2,” respectively. Events originating from the coalition are prefixedwith “c,” e.g., “cRun,” while events without any prefix originate fromthe entity where they are used.

[0145] In FIG. 7, task l1 330 receives an event cRun 704 from thecoalition, and enters a tentative state tRunning 706. Task l1 330 thenpasses on an event l1_(tRun) 604 to task k1 310, and task k1 310 thenenters a state running 606, and sends an event k1_(run) 708 to task l1330. Task l1 330 then enters a state running 710. If task k1 310 sends anoCommit event 712 instead, indicating that it was not able to performthe request, then task l1 330 returns to its original not_Started state702. If the workflow K 302 is instantiated without coalition request byits own workflow engine 410, then the following exchange of events takesplace. First, task k1 310 enters the state running 606 using a requestto its workflow engine 410, and sends the event k1_(run) 708 to task l1330. Task l1 330 then enters the state running 710.

[0146] A remainder of states and events in FIGS. 6 and 7 mirror thediscussion of FIG. 5 above, in the context of task k1 310, task k2 312,and task l1 330. For example, while running, task k1 310 might receive asuspend command 608 from task l1 330, and enter into a suspended state610. This state might lead to a terminate message 612 from task l1 330,and thereby a terminated state 614, or to an abort message 616, andthereby to an aborted state 618. Of course, the not_Started state 602could also lead to either the terminated state 614 or the aborted state618, as well.

[0147] The running state 606 might also lead to a complete event 620,which in turn leads to the completed state 622. In this case, task k1310 is instantiated as complete in event 624, and task k2 312 entersinto an open_not_Started state 626. Task k2 312 proceeds as justdescribed with respect to task k1 310, with a run event 628, a runningstate 630, a suspend event 632 and a suspended state 634, a terminateevent 636 and a terminated state 638, an abort event 640 and an abortedstate 642, and a complete event 644 and a completed state 646.

[0148] In FIG. 7, the running state 710 may lead to a cSuspend event 714(i.e., a suspend command from the coalition), which leads to atSuspended state 716. The tSuspended state may lead to a “no commit”event 718 from either task k1 310 or task k2 312, which would returntask l1 330 to the running state 710. The tSuspended state 716 mightalso lead to a suspend command 720 (which could also stem directly fromthe running state 710) for task k1 310 or task k2 312, which would leadtask l1 330 into a suspended state 722.

[0149] The suspended state 722 might lead to a cTerminate event 724, andthereby to a tTerminated state 726. The tTerminated state 726 leads toeither an actual termination event 728 from task k1 310 or task k2 312,and thereby to a terminated state 730, or to a “no commit” event 732from task k1 310 or task k2 312, and thereby back to the suspended state722.

[0150] The suspended state 722 may also lead to a cAbort event 734, andthereby to a tAborted state 736, which in turn leads to either a “nocommit” event 738 (and thereby back to the suspended state 722) or to anactual abort event 740 for task k1 310 or task k2 312, with anassociated aborted state 742. The suspended state 722 might also lead toa cAbort event 744 and following tAborted state 746, which leads eitherback to the abort event 740 or to a “no commit” event 748 with respectto task k1 310 or task k2 312 (which in turn leads back to thenot_Started state 702. Finally with respect to the suspended state 722,it may also lead back to the cRun event 704.

[0151] The running state 710 also leads to a cTerminate event 750, andthen to a tTerminated state 752, which leads to either a “no commit”event 754 (and then back to the running state 710) or to a k1 310 or ak2 312 terminate event 728 that leads to the terminate state 730. Therunning state 710 also leads to a cAbort event 756, which results in atAborted state 758. The tAborted state 758 either leads further to theabort event 740, or to a “no commit” event 760 (and thereby back to therunning state 710).

[0152] Finally with respect to FIG. 7, the running state 710 may lead toa cComplete event 762, which in turn leads to a tCompleted state 764.The tCompleted state 764 leads to either a “no commit” event 766 fromtask k2 312 (and thereby back to the running state 710), or to acomplete event 768 (which may also follow directly from the runningstate 710, without requiring a message from the coalition), and thus toa final completed state 770.

[0153] Although task k1 310 and task k2 312 execute in series in FIGS. 6and 7, a general structure of the Petri-Net of task l1 330 (i.e., FIG.7) would remain unchanged in the situation where task k1 310 and task k2312 in parallel. However, the events from the private tasks would becorrelated differently. For example, task l1 330 could only complete ifboth of tasks k1 310 and k2 312 completed.

[0154] As discussed above, control flow dependencies may beadvantageously used to connect workflow view tasks from multipleentities into a single, collaborative workflow. Control flowdependencies allow for a way to connect a closed state of one task to anopen state of the next task, in a flexible and autonomous way. Incontrast, state dependencies may be more suited to connect a particularworkflow view task to its underlying actual workflow task(s), sincestate dependencies provide for accurate and timely interchanges betweentasks and workflow view tasks regarding their respective state changes.

[0155] In performing the various messaging functionalities between theparties involved in a collaborative workflow, content-based messagingmay be used, in which messages are routed on the basis of their content.Additionally, dedicated communications channels can be used formessaging. Messaging may be made persistent by the use of elements suchas the message queue 452 in FIG. 4, or similar elements, which need notnecessarily be implemented in the context of a mediator.

[0156] Messages may have various dependencies on (i.e., correlationswith) one another, derived from the content of messages or frommeta-information external to the message itself, such as the timeframein which messages have been created or received. There may also beordering dependencies between messages. These ordering dependencies mayexpress that message 1 must be processed before message 2. For example,an “order confirmation” has to be processed before the shipmentnotification can be processed. There may also be causal dependenciesbetween messages. A change order depends on its corresponding order.Messages can be invalidated. Subsequent change order messages invalidateprevious change order messages and other causal dependent messages, suchas the original order or the shipment notification. Such correlationinformation may be derived from private workflow(s), and be made visiblein a workflow view. Once workflow views are combined into coalitionworkflows, it can be validated that correlation requirements in thecoalition workflow can be satisfied. In this case, “correlators” may beused in place of, or in addition to, the “AND-join” tasks discussed indetail herein. In this case, workflow data flow on an instance levelshould be considered, along with issues related to data formatting andsemantic understanding of data that is to be correlated.

[0157]FIG. 8 is a block diagram of a task illustrating the task inputsand outputs types of relevant data. In FIG. 8, a task t 802 manipulatesdata, where the data reflects real-world information aboutimplementation of the task. For the task t 802, Dti represents inputdata of task t 802 that task t 802 requires to enter the state running,i.e. to commence operations. Dte represents data that task t 802exchanges while it is in a state open.running, i.e., while task t 802 isoperating to achieve its business objective(s), and Dtr representsoutput data of task t 802 to some other task when it enters the stateclosed, i.e., when t ends its operation. The union of task-relevant datafrom all tasks of a workflow form workflow-relevant data.

[0158] The term “union of data,” for example in a database context,generally refers to a combination of results of two or more queries intoa single result set consisting of all the rows belonging to all queriesin the union. The union of data concept can be usefully applied in thepresent context as well.

[0159] For example, in FIG. 3, considering task k1 310 and task k2 312in relation to task l1 330, input data of task l1 330 is a subset of, orequal to, the input data of task k1 310, and output data of task l1 330is a subset of, or equal to, the output data of task k2 312. Thus,exchange data of task l1 330 is a subset of, or equal to, the union ofexchange data of task k1 310 or task k2 312. More generically, exchangedata of any abstracted task “l” will be a subset of, or equal to, theunion of exchange data of tasks “k” associated with the abstracted task.

[0160] In the context of collaborative workflows as described above withrespect to FIGS. 1-7, the union of exchange data of tasks “k” should bemodeled with consciousness of the fact that once a view task “l” is aview task of many tasks “k” that require interaction with the coalition,coalition partners would not be aware in which order they have toexchange data with task “l.” Thus, there should be a maximum of one task“k” within a workflow K such as workflow K 302 that requires dataexchange with the coalition through view task “l.” Of course, tasks “k”would still be capable of exchanging data within their own organisation,assuming workflow K is a private workflow in which details are all knownto its owning entity.

[0161] Also in the context of collaborative workflows as described abovewith respect to FIGS. 1-7, interchanges between workflows can beachieved by at least the following two techniques: (1) acommonly-adopted process definition language (meta-model), or (2)commonly-agreed interfaces/message formats. The latter is a partialsolution, as it enables invocation semantics (interaction at thebusiness process execution level), while the former allows fullinteroperability because it enables business processes to interact atthe level of any modelling element—as if it were a single organizationalbusiness process.

[0162] Common process definitions or a common meta-model would requireadoption of a common process definition language by workflow vendors,and would allow true interoperability of business processes supported bydifferent workflow engines. However, this goal may not always be easilyachievable.

[0163] On the other hand, process interoperability standards at aninterface layer are more widely and easily supported by industry andworkflow vendors. Generally speaking, communication-interoperabilitybetween workflow management systems can be realized by, for example,direct interaction of workflow management systems via a set ofstandardized functions, message-passing between the systems, use ofshared data stores (e.g. commonly accessible repositories) by thesystems, or bridging of systems using gateways to connect differentprotocols and formats (as discussed in more detail with respect togateways 418 and 444 in FIG. 4). These four approaches tocommunication-interoperability are not necessarily exclusive of oneanother.

[0164] In a mediated environment such as that just described, there isone central participant that is able to route information to thecommunication partners, which do not have to know each other. Priorknowledge about the mediator is sufficient. All or some communication isrouted through the mediator, which decouples the sender and receiver ofinformation and sets the number of individual communication paths at 2n,where n is the number of participants.

[0165] In contrast, in a peer-to-peer (P2P) environment, allcommunication partners directly know about each other. They may still beusing Internet services, such as the eServices repository 448 or thecertificate authority 422. However, all communications are directbetween the communication partners. This requires that all theparticipants agree on a method of interaction. Also, the number ofindividual communication paths between participants is higher than in amediated environment, and equal to (n2−n).

[0166] Mediation has at least two facets: (1) stateless, in which themediator passes messages from sender to receiver, and (2) statefulmediation, which may be either passive or active. Stateful mediationallows the matching of request and respond messages, and assignment ofthe messages to the right participant, particularly in scenarios wherethe participants do not want to know about each other.

[0167] In passive stateful mediation, the characteristics of statelessmediation are included, along with the ability to log the interaction(s)in a persistent storage, thereby facilitating monitoring and errorhandling. In active stateful mediation, the aspects of passive statefulmediation are included, along with an ability to actively drive thepartners' interaction by executing a coalition workflow and invoking thecommunication partner's IT systems to perform their work.

[0168] It is possible for a central workflow engine to mediate theinteraction of the partners' workflow systems. In this case, thecoalition workflow is physically instantiated, which provides theadvantage of facilitating monitoring. Specifically, the coalitionworkflow reflects the states of the involved workflow views, whichreflect the states of their corresponding private workflows. Amonitoring tool can directly display the coalition's workflow statusinformation, and there is no need to collect monitoring data from theinvolved work-flow views.

[0169] A stateful mediation also may be achieved through statelessmediation plus a set of supporting services, such as a centralmonitoring service, as opposed to a central workflow engine. In thiscase, there is no real need for a central state machine to run acoalition workflow, because there are already the individual statemachines that execute their respective private workflows.

[0170] In a mixed approach, stateless and stateful mediation servicesare used where required by the communication partners. In such cases,mediation is used for monitoring, persistence of messages and foroffline-support, while other information is exchanged directly been thecommunication partners.

[0171] The remainder of Section I is devoted to a discussion ofeServices, such as those implemented in the eService repository 448 inFIG. 4. Generally speaking, as referred to above, eServices areabstractions of business tasks and entire business processes anddescribe their capabilities and requirements. Therefore, eServices (alsoknown as Web Services) may be well-suited to assist in hidingenterprise-internal systems details from the outside world, whilepreserving or enabling the systems' capabilities to participate ininter-organizational business processes.

[0172]FIG. 9 is a block diagram of an eService 900. In FIG. 9, eService900 is an entity that provides information on itself through white pages902, its owning entity through yellow pages 904, its technicalrequirements, such as invocation parameters and protocols through greenpages 906, and a description of how to perform complex businesstransactions step-by-step through process pages 908. Also in eService900, local information including process logic 910, application logic912, and data in a database 914 allow the eService to implement itsservices for consumers.

[0173] The following discussion describes relevant metadata required toexpress eServices, without regard to their provided service and theirindustrial domain. An eService specification generally allows for human-and machine readability of eServices information.

[0174] White pages 902 provide the specifics about an eService in termsof which purpose it serves, based on standard taxonomies. The whitepages 902 may include, for example, a human-readable name anddescription of the eService (with industry-specific terminology), anidentifier of the eService, availability information about the eService,and price/payment information about the eService.

[0175] Yellow pages 904 provide general information about a provider ofeSservices. They generally include, for example, the name and address ofthe business, and a contact person within the business.

[0176] Green pages 906 provide information about the specifics oftechnical interaction with an eService. This information might include,for example, interaction information (e.g., contact information), and aninput/output (“I/O”) description.

[0177] Process pages 908 assist in describing interaction behavior(including technical information) of the eServices, and are thus relatedin function to the green pages 906. More specifically, simple eServicesare instantiated with a set of input attributes, and (at the end oftheir instance life cycle) deliver an output set of attributes. Complexservices are able to interact as, for example, a workflow is able tocommunicate with its outside world to require further input data or todeliver intermediate results. To be able to correctly integrate aneService, it is therefore necessary to describe both the neededinteractions and an order in which the interactions are required, andprocess pages 908 assist in this functionality.

[0178] In describing relevant metadata required to express eServices,various entity-types and attributes may be included in across-organizational workflow meta-model. Such a model is sufficient forquerying, monitoring and verifying global and local processes, andserves as a blueprint for their evolution and maintenance. Themeta-model identifies a common set of attributes that are required forcross-organisational workflows to interact efficiently in cooperationwith the above white pages 902, yellow pages 904, and green pages 906.

[0179] A first entity in the meta-model, and the most general, is thecoalition. The coalition may represent, for example, a virtualenterprise, extended enterprise, or virtual organization. It is formedby a number of members that have agreed to cooperate for a particularperiod of time towards a common goal. A default method of interactionsmay be used to describe the technical interaction(s) preferred in thecoalition, while security rights describe the partners' rights to add,modify, view, and delete workflows. Table 2 provides information aboutthe coalition entity. TABLE 2 Coalition Attribute Description List ofMembers Members that form the coalition Validity The time of thecoalition's existence, expressed as start and end date and time DefaultMethod of Interaction Technical interaction preferred in the coalition.Can be overwritten by the workflow or activity Security Rights Rights toadd, modify, delete, and view workflows

[0180] Workflow is an entity that represents private partner workflows,workflow views and coalition workflows, thus providing a protocol tointeract with tasks within these various workflows. Table 3characterizes information about the workflow entity. TABLE 3 WorkflowAttribute Description Type {Partner, View, Coalition} Relationship toother workflow Is view of partner workflow/Is element entities ofcoalition workflow Process start and termination Conditions under whichworkflow starts conditions and closes Security, audit, control dataPermission to start/interact with a workflow Specification languageRequired to interpret the flows, decisions, etc. resolving the semanticintegration issues. Coalitions Back-reference to the coalitions thatthis workflow belongs to Owner Owner of the workflow Supporting WfMSWfMSs that are able to execute this workflow. Dependencies:specification language, underlying organizational model, availableresources Location Location of the Engine: geographical data. ActivitiesList of activities Default Method of Interaction Technical interactionpreferred in the coalition. Can be overwritten by the workflow oractivity Transition Conditions Transitions between the workflowsactivities and subworkflows

[0181] An activity entity type represents the tasks in a workflow.Besides activity I/O data for an activity, communication requirements,i.e. the messages to be interchanged with the environment duringexecution time, should also be considered. It should be noted that, eventhough an activity may be atomic, the underlying implementation mayrequire executing several steps to perform the activity. Table 4characterizes information about the activity entity. TABLE 4 ActivityAttribute Description Type subflow, atomic flow, etc. Pre-andpost-conditions Conditions for activity to commence/ finish Otherscheduling Such as temporal dependencies constraints PerformingWf-Engine All engines that are involved in executing this workflow.Required for distributed workflows. Activity share-ability (exportable,private/internal only) Activity input data Data required by activity atthe start of its lifecycle Activity output data Data produced byactivity at the end of its lifecycle Activity communication Emitted andconsumed messages with the outside world during the activity'slifecycle. Required to realize more complex protocol interactions.Ownership Ownership of the activity Default Method of Technicalinteraction preferred in the activity. Interaction Usually identical tothe workflow's default method of interaction. Can be overwritten ifactivity is performed by external application, or a human Role The rolethat performs the activity

[0182] A transition condition describes the paths among workflows andactivities. The information about them is useful in forming workflowviews. With the introduction of the coalition entity above, there can be“coalition-transitions” connecting publicly visible workflows/activitiesand internal-transitions within the private workflow of theorganizations. If there is the need to expose an internal-transition tothe coalition because it is part of a coalition-wideJOIN/SPLIT-condition, then this may be made visible by setting atransition share-ability attribute. Table 5 characterizes informationabout transition conditions. TABLE 5 Transition Conditions AttributeDescription Flow condition Edge been information source and informationsink Transition Share-ability Exportable/private/internal only

[0183] The implementation entity describes an implementation of anactivity. A separation between activity entity type and implementationentity type is particularly sensible when coalition participantsdynamically implement activities, such as in an eMarketplace, where thecross-organisational workflow should stay unchanged, but the binding toa particular implementation should be modified. Table 6 characterizesinformation about the implementation entity. TABLE 6 ImplementationAttribute Description Execution parameters Parameters required toexecute the implementation Location or access path Execution semanticsWorkflow The workflow that implements this implementation Activity Theactivity that implements this implementation

[0184] A workflow relevant data entity is used by the workflow itself,and influences the transitions between the views. There is no cleanseparation between application data and workflow relevant data, as theresults of the application operation influence the workflow'stransitions. A role is the entity in the model that describes theperformer of an activity. It reflects an entity in an organization andprovides information how to possibly contact the role implementer.

[0185] When a service consumer requests an eService from a serviceprovider, the service consumer generally specifies required attributesand their values, and launches a query in an eService repository. Thequery delivers back to the service consumer a set of services that matchthe query, and the service consumer then refines the query and selectsone or more services.

[0186] The services are then bound to the service consumer's businesstask. When there is a strong requirement on an availability of theeService, then a set of similar eServices would be tentatively bound toa business task as well, so that, at runtime, one of them could beselected according to its availability. The business task of the serviceconsumer can be atomic, or can be part of a business process that can berepresented by a workflow.

[0187] At this point, the eServices are invoked, and data is sent fromthe service consumer to the service provider. Interaction may then occurwith the services, and data is interchanged between the consumer and theprovider. Once the eServices report their completion, the provider sendsrequired data to the consumer. In this interaction model, a provider mayinvoke further eServices from another provider, thus becoming a serviceconsumer.

[0188] In the description above, steps can be carried through prior tothe start of the service consumer's business process (early binding), orduring its execution (late binding of eServices). The binding of aneService to a corresponding business task of the service consumer may bedone manually or automatically.

Section II

[0189] Section I above discusses described implementations ofcross-organizational, collaborative workflows, in which privateworkflows, each associated with an individual organization, arerepresented as abstracted “workflow views.” The workflow views arejoined together with their respective workflows using statedependencies, and are joined within the collaborative workflows, usingcontrol flow dependencies.

[0190] In constructing workflow views from workflows (and vice versa),it would be advantageous to have techniques for doing so in a mannerwhich maintains the state dependencies just referred to, and which doesnot allow for any inconsistencies between an operation of the workflowview and its underlying workflow. For example, in a case where twoparallel tasks in a workflow must both be completed for the workflow toproceed, it would be inconsistent to have the tasks associated with,respectively, two workflow view tasks in series with one another. Such asituation might result in the case where one of the parallel workflowtasks finishes before the other, thereby authorizing a completion of thefirst workflow view task and a corresponding starting of the secondworkflow view task, even though the second actual task is not yetfinished (indeed, may not even be started).

[0191] Similarly, it would be advantageous to have techniques forquickly, easily, and reliably adding the control flow dependenciesbetween and among the workflow view tasks within the collaborativeworkflows.

[0192]FIG. 10 is a diagram illustrating operations for modifying one ormore workflows. In FIG. 10, a first operation 1002 is generalization, inwhich a workflow is made more abstract (e.g., when a workflow isconverted into a workflow view). A second operation 1004, which is theinverse of generalization, is specialization, in which a workflow ismade less abstract, or more specific (e.g., when a workflow view isconverted into a workflow).

[0193] A third operation 1006 is expansion, in which a workflow isjoined with another workflow by an addition of, for example, controlflow dependencies including routing and synchronizing tasks. Finally, afourth operation 1008 is reduction, which is the inverse of expansionand which removes or reduces a collaborative workflow of some type intotwo or more individual-workflows. Expansion and reduction are discussedin more detail in Section III.

[0194] The following discussion of Section II thus describes techniquesfor transforming an abstraction level of a workflow, i.e., making itmore or less abstract, while maintaining state dependencies between theoriginal workflow and the transformed workflow. These techniques may beused in the collaborative workflows discussed above in Section I, butmay also be used on their own. For example, a company may want tomaintain privacy of its workflow by generating an associated workflowview, even if that workflow view is not necessarily going to be used ina collaborative workflow.

[0195] In discussing these and related concepts, the followingterminology is used. Workflow W is considered to be a set of tasks thaving dependencies d between the tasks, where T is a nonempty set oftasks within the workflow and D is a nonempty set of dependenciesbetween tasks in t. A task t represents the work to be done to achievesome given objectives within a workflow, and can represent bothautomated and manual tasks. Tasks are performed by assigned processingentities.

[0196] Tasks are further classified into three types: activity (A),sub-workflow (SW), and route (R). An activity is atomic and is animplementation of a task. A sub-workflow is a composite task that is aplaceholder for another workflow. A route task permits the expression ofdependency conditions, and includes the AND-split (AS), AND-join (AJ),XOR-split (XS), and XOR-join (XJ), the functions of which are discussedin more detail below.

[0197] A dependency d defines the execution dependency between twoobjects in a workflow model. By connecting tasks through dependencies,the dependencies may represent the edges of an adjacent digraph, whiletasks represent vertices. More specifically, a directed graph or digraphD, is a finite, nonempty set V(D)={v1, v2, . . . vn} of vertices and apossibly empty set E(D) of ordered pairs of distinct vertices. Theelements of E(D)={e1, e2, . . . em} are called arcs. The underlyinggraph of a digraph D is that Graph G obtained from D by replacing allarcs (u, v) or (v, u) by the edge uv. The number of vertices in adigraph D is called its order, which is denoted as p=order(D) and thenumber of arcs in D is its size, denoted as q=size(D). A digraph oforder p and size q is called a (p, q) digraph. If (u, v) is an arc of D,then u is said to be adjacent to v and v is adjacent from u. Further,the arc (u, v) is incident from u and incident to v. The outdegree od(v)of a vertex v in a digraph D is the number of vertices adjacent from vand the indegree id(v) of v is the number of vertices adjacent to v. Thedegree deg(v) of a vertex v in D is defined by deg (v)=od (v)+id (v).

[0198] If D is a digraph of order p and size q, with V(D)={v1, v2, • ••, vp}. Then $\begin{matrix}{{\sum\limits_{i = 1}^{p}{{od}\left( v_{i} \right)}} = {{\sum\limits_{i = 1}^{p}{{id}\left( v_{i} \right)}} = q}} & {{Eq}.\quad (1)}\end{matrix}$

[0199] A walk in D is an alternating sequence W: v0, e₁, v₁, e₂, v₂, . .. , v_(n−1), e_(n), v_(n) (n≧0) of vertices and arcs beginning andending with a vertex such that e_(i)=(v_(i−1), v_(i)) for each i with1≦i≦n. The walk W is a v0-vn walk of length n. A trail is a walk inwhich no edge is repeated and a path is a walk in which no vertex isrepeated. Thus, a path is a trail, but not every trail is a path.

[0200] Two vertices u and v in D are connected if D contains a u-v walk.For a vertex v of D, its neighborhood N(v) (or NG(v)) is defined by:

N(ν)={u∈V(D)|(ν, u)∈E(D)v(u, ν)∈E(D)}  Eq. (2)

[0201] The adjacency matrix Dp×p=[di j] of a (p, q) digraph D is the (p,p) matrix defined by: $\begin{matrix}{d_{i,j} = \left\{ \begin{matrix}{1,{{{if}\quad \left( {v_{i},v_{j}} \right)} \in {E(D)}}} \\{0,{otherwise}}\end{matrix} \right.} & {{Eq}.\quad (3)}\end{matrix}$

[0202] The number of components in a digraph is denoted as k(D). In aconnected graph, k(D)=1. A structure S is a subset of a digraph D. Itis: V(S)⊂V(D) and E(S)⊂E(D). An exchange of elements in a matrix D isrepresented with:

d_(i,j)

d_(k,j)|i, j,k,l∈N⁺

1 ≦i, j,k,1≦d  Eq. (4)

[0203]FIG. 11 shows a digraph 1100. In FIG. 11, there is a task m1 1102,a task m2 1104, a task m3 1106, a task m4 1108, a task m5 1110, a taskm6 1112, and a task m7 1114. Pairs of the tasks are joined bydependences, including a dependency m1,2 1116 joining task m1 1102 totask m2 1104, a dependency m2,3 1118 joining task m2 1104 to task m31106, a dependency m3,4 1120 joining task m3 1106 to task m4 1108, adependency m3,5 1122 joining task m3 1106 to task m5 1110, a dependencym4,6 1124 joining task m4 1108 to task m6 1112, a dependency m5,6joining task m5 1110 to task m6 1112, and a dependency m6,7 1128 joiningtask m6 1112 to task m7 1114.

[0204] Using the techniques and notations described above, the digraph1100 can be represented as an adjacency matrix, as shown in Eq. (5):$\begin{matrix}{M = \begin{bmatrix}0 & 1 & 0 & 0 & 0 & 0 & 0 \\0 & 0 & 1 & 0 & 0 & 0 & 0 \\0 & 0 & 0 & 1 & 1 & 0 & 0 \\0 & 0 & 0 & 0 & 0 & 1 & 0 \\0 & 0 & 0 & 0 & 0 & 1 & 0 \\0 & 0 & 0 & 0 & 0 & 0 & 1 \\0 & 0 & 0 & 0 & 0 & 0 & 0\end{bmatrix}} & {{Eq}.\quad (5)}\end{matrix}$

[0205] As should be understood from the above, the matrix M representsthe digraph 1100 in that dependency m1,2 1116 is represented as the “1”in the first row, second column of matrix M. Similarly, dependency m2,31118 is represented as the “1” in the second row, third column of matrixM. The third row of matrix M has two “1s,” the first, in the thirdcolumn, representing dependency m3,4 1120, and the second, in the fourthcolumn, representing dependency m3,5 1122. Similar comments apply todependencies m4,6 1124, m5,6 1126, and m6,7 1128.

[0206] A workflow M is well-defined if it satisfies the conditions ofworkflow, task, and dependency, as defined above, if it includes atleast one task, has only one input task and one output task, isconnected, and has no task that links to itself. In this case, workflowM can be expressed as in Eq. (6): $\begin{matrix}{{\lbrack M\rbrack_{p \times p} \times {\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1} \\m_{2}\end{matrix} \\\vdots\end{matrix} \\m_{p}\end{bmatrix}\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1} \\m_{2}\end{matrix} \\\vdots\end{matrix} \\m_{p}\end{bmatrix}}},{{where}\quad m_{1}},m_{2},\quad {{{\ldots \quad m_{p}}\quad \in {{V(M)}\quad {and}\quad p}} = {{order}(M)}}} & {{Eq}.\quad (6)}\end{matrix}$

[0207] From Eq. (6), the operator ← is referred to herein as “precedes,”or “the precedes operator,” while x represents a standard matrixmultiplication.

[0208] In graph terms, the precedes-operator is implies that there is apath from a vertex that is represented by an element in the matrixsituated on the right hand side of the operator, $\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1} \\m_{2}\end{matrix} \\\vdots\end{matrix} \\m_{p}\end{bmatrix},$

[0209] to a vertex that is represented in the matrix situated on theleft hand side of the operator, $\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1} \\m_{2}\end{matrix} \\\vdots\end{matrix} \\m_{p}\end{bmatrix}.$

[0210] In FIG. 11, if task m3 1106 is of type AS (AND-split), and taskm6 1112 is of type AJ (AND-join), then digraph (workflow) 1100 can berepresented as shown in Eq. (7): $\begin{matrix}{\begin{bmatrix}0 & 1 & 0 & 0 & 0 & 0 & 0 \\0 & 0 & 1 & 0 & 0 & 0 & 0 \\0 & 0 & 0 & 1 & 1 & 0 & 0 \\0 & 0 & 0 & 0 & 0 & 1 & 0 \\0 & 0 & 0 & 0 & 0 & 1 & 0 \\0 & 0 & 0 & 0 & 0 & 0 & 1 \\0 & 0 & 0 & 0 & 0 & 0 & 0\end{bmatrix} \times {\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1A} \\m_{2A} \\m_{3{AS}} \\m_{4A} \\m_{5A}\end{matrix} \\m_{6A\quad J}\end{matrix} \\m_{7A}\end{bmatrix}\begin{bmatrix}\begin{matrix}\begin{matrix}m_{1A} \\m_{2A} \\m_{3{AS}} \\m_{4A} \\m_{5A}\end{matrix} \\m_{6A\quad J}\end{matrix} \\m_{7A}\end{bmatrix}}} & {{Eq}.\quad (7)}\end{matrix}$

[0211] By carrying through the matrix multiplication, the following setof precedes relationships is obtained, expressed in Eq. (8):$\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\left. {m2A}\leftarrow{m1A} \right. \\\left. {m3AS}\leftarrow{m2A} \right.\end{matrix} \\\left. {{m4A} + {m5A}}\leftarrow{m3AS} \right.\end{matrix} \\\left. {m6AJ}\leftarrow{m4A} \right.\end{matrix} \\\left. {m6AJ}\leftarrow{m5A} \right.\end{matrix} \\\left. {m7A}\leftarrow{m6AJ} \right.\end{matrix} & {{Eq}.\quad (8)}\end{matrix}$

[0212] The expressions having the same left hand side m6AJ can becombined, and the ‘+’ operator may be interpreted as a conjunction. Itsoperation is defined by the task-type on the right hand side of theequation. In the above cases of m4A+m5A←m3AS, the ‘+’ operator expressesthat m3AS precedes m4A AND m5A. In the second case of m6AJ←m4A andm6AJ←m5A, m4A AND m5A precede m6AJ. This allows simplification of Eq.(8) to Eq. (9): $\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\left. {m2A}\leftarrow{m1A} \right. \\\left. {m3AS}\leftarrow{m2A} \right.\end{matrix} \\\left. {{m4A} + {m5A}}\leftarrow{m3AS} \right.\end{matrix} \\\left. {m6AJ}\leftarrow{{m4A} + {m5A}} \right.\end{matrix} \\\left. {m7A}\leftarrow{m6AJ} \right.\end{matrix} & {{Eq}.\quad (9)}\end{matrix}$

[0213] Expressions including XOR-splits and XOR-joins can be treatedanalogously. For example, in the expression m4A+m5←m3XS, the ‘+’operator would be interpreted that m3XS precedes either m4A or m5A. Inm6XJ←m4A+m5A, either m4A or m5A precedes m6XJ.

[0214] Returning to FIG. 10, the operation 1002 of generalization andthe operation 1004 of specialization can be described in terms of theabove terminology. For example, generalization, as referred to above,serves to make a workflow more generic (or abstract). This process canbe though of as one in which one or more vertices in a workflow arerepresented by a single vertex in a workflow view. In contrast,specialization makes a workflow more specific, so that at least onevertex in a workflow view is represented by one or more vertices of aworkflow.

[0215] The following additional terminology is used in the belowdiscussion: g(K) is the generalisation of a workflow K, and s(K) is thespecialisation of workflow K. As discussed below, for eachspecialization of K there exists a generalisation such that g(s(K))=K,and vice versa, s(g(K))=K. In FIG. 3, for example, workflow view L 304is one possible generalization of workflow K 302, while workflow K 302is one possible specialization of workflow L 304. In FIG. 3, therelationships between abstract tasks including task l1 330, task l2 332,or task l3 334 to their corresponding specialized tasks in workflow K302 are represented by curved connectors.

[0216]FIG. 12 is an illustration of a specialization operator 1200. Morespecifically, FIG. 12 illustrates the I-specialization of M, an (m,m)matrix, and N, an (n,n) matrix, where the I-specialization is written asMs(1)N=R, where R is a matrix of size (r, r) with r=m−1+n, such that theml column of M and the ml row of M is replaced with n1, n2, • • •, nnrows and columns of N. The elements of R=Ms(1)N are defined such that iis a row index and j is a column index of R, and i, j∈N+, where N+ isthe set of natural positive numbers. Then the elements of R, r_(i,j),are defined by Eq. 10: $\begin{matrix}{r_{i,j} = {\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}\begin{matrix}{m_{i,j}{{\left( {0 < i < 1} \right)\bigwedge\left( {0 < j \leq 1} \right)}}} \\{m_{i,{{j.n} + 1}}{{\left( {0 < i < 1} \right)\bigwedge\left( {{1 + n} \leq j \leq r} \right)}}}\end{matrix} \\{m_{{i + {1.n}},j}{\left( {{1 + n} \leq i \leq r} \right)\bigwedge\left( {0 < j \leq 1} \right)}}\end{matrix} \\{m_{{i + 1 - n},{{j.n} + 1}}{\left( {{1 + {n{.1}}} \leq i \leq r} \right)\bigwedge\left( {{1 + n} \leq j \leq r} \right)}}\end{matrix} \\{n_{{i - 1 + 1},{{j{.1}} + 1}}{\left( {1 \leq i < {n + 1}} \right)\bigwedge\left( {1 \leq j < {n + 1}} \right)}}\end{matrix} \\{m_{1,j}{\left( {i = {1 + {n{.1}}}} \right)\bigwedge\left( {1 \leq j \leq 1.1} \right)}}\end{matrix} \\{{0{{all}\quad {other}\quad i}},j}\end{matrix}\quad \begin{matrix}(1) \\(2) \\(3) \\(4) \\(5) \\(6) \\(7)\end{matrix}}} & {{Eq}.\quad (10)}\end{matrix}$

[0217] In Eq. 10, the individual portions labeled (1)-(7) are referredto hereafter as expressions, for example, expression (1) or expression(2).

[0218] In FIG. 12, expression (1) is a matrix portion 1202, expression(2) is a matrix portion 1204, expression (3) is a matrix portion 1206,expression (4) is a matrix portion 1208, expression (5) is a matrixportion 1210, expression (6) is a matrix portion 1212, and expression(7) is represented by remaining portions of the specialization operator1200 being set to the value “0.”

[0219] Functionally, expressions (1), (2), (3), and (4) serve to copythe matrix M into the matrix R. Expression (5) enters the matrix N as awhole into the matrix R. Expression (6) connects remaining verticesm_(i), that were adjacent from m_(i), to n_(i,l).

[0220] Thus, the specialization operator 1200 serves to link (i.e.,insert the curved lines indicating dependencies, as in FIG. 3) one ormore workflow tasks within a workflow view represented by matrix M(analogous to workflow view L 304 in FIG. 3) with one or more taskswithin matrix N (analogous to workflow K 302 in FIG. 3). As will beshown in more detail below, such linking, when performed improperly, canlead to inconsistencies between a workflow view and its correspondingworkflow, which in turn may lead to failed state dependencies and/ormiscommunication between an entity implementing the workflow and othermembers of a coalition.

[0221]FIG. 13 is a matrix 1300 illustrating an algorithm for computingspecialization. The algorithm is consistent with Eq. (11), defining anintermediate matrix R*, of size (r*, r*) with r*=m+n, and assuming thati, j∈N+, so that Eq. (11) is: $\begin{matrix}{r_{i,j}^{*} = \begin{matrix}{{m_{i,j}{{\left( {0 < 1 \leq m} \right)\bigwedge\left( {0 < j \leq m} \right)}}}} & (1) \\{{n_{{i - m},{j - m}}{{\left( {m < i \leq {m + n}} \right)\bigwedge\left( {m < j \leq {m + n}} \right)}}}} & (2) \\{{r_{i,1}^{*}{{\left( {0 < i \leq m} \right)\bigwedge\left( {j = {m + 1}} \right)}}}} & (3) \\{{r_{1,j}^{*}{{\left( {i = {m + 1}} \right)\bigwedge\left( {0 < j \leq m} \right)}}}} & (4) \\{{0{{{{all}\quad {other}\quad i},j}}}} & (5)\end{matrix}} & {{Eq}.\quad (11)}\end{matrix}$

[0222] In FIG. 13, expression (1) is a matrix portion 1302, expression(2) is a matrix portion 1304, expression (3) is a matrix portion 1306,expression (4) is a matrix portion 1308, and expression (5) isrepresented by remaining portions of the matrix 1300 being set to thevalue “0.”

[0223] Expression (1) and expression (2) serve to expand M by N at rowand column number (m+1,m+1). Expression (3) and expression (4) serve tolink from M to N appropriately, and expression (5) serves to remove therow 1 and the column 1 from R*. The resulting matrix is P of size(m+n−1, m+n−1).

[0224]FIG. 14 is an illustration of a generalization operator 1400. Fora matrix M that is a (m,m) matrix, the k,l-generalisation is R=M g(k,l), where Mg(k, l) is a matrix, such that the k, . . . , 1 columns of Mare replaced with a single row and column. The elements of R, wherein Ris a (r, r) matrix with r=m+k−1, are defined below in Eq. 12, wherein iis a row index and j is a column index, and i, j E N+. Then Eq. (12) is:$\begin{matrix}{r_{i,j} = \begin{matrix}{{m_{i,j}{{\left( {0 < i < k} \right)\bigwedge\left( {0 < j \leq k} \right)}}}} & (1) \\{{m_{i,{j - k + 1}}{{\left( {0 < i < k} \right)\bigwedge\left( {{k + 1} \leq j \leq r} \right)}}}} & (2) \\{{m_{{i - k + 1},j}{{\left( {{k + 1} \leq i \leq r} \right)\bigwedge\left( {0 < j \leq k} \right)}}}} & (3) \\{{m_{{i -},{k + 1},{j - k + 1}}{{\left( {k \leq i \leq r} \right)\bigwedge\left( {{k + 1} \leq j \leq r} \right)}}}} & (4) \\{{0{{\left( {i = k} \right)\bigwedge\left( {j = k} \right)}}}} & (5) \\{{m_{1,j}{{\left( {i = k} \right)\bigwedge\left( {0 < j \leq {k - 1}} \right)}}}} & (6)\end{matrix}} & {{Eq}.\quad (12)}\end{matrix}$

[0225] In FIG. 14, expression (1) is a matrix portion 1402, expression(2) is a matrix portion 1404, expression (3) is a matrix portion 1406,expression (4) is a matrix portion 1408, expression (5) is representedby remaining portions of the generalization operator 1400 being set tothe value “0,” and expression (6) is a matrix portion 1410.

[0226] Functionally, expressions (1) and (3) copy the respective m_(i,j)from M into R, and link vertices that were formerly adjacent to m_(i,k)to r_(i,k). Expressions (4) and (6) connect the vertices that wereadjacent from ml, j to rk, j. Expression (2) is only concerned withcopying mi, j from M into R, and has no influence on the re-linking ofthe elements in R.

[0227]FIG. 15 is a matrix 1500 illustrating an algorithm for computinggeneralization. The algorithm is consistent with Eq. (12), defining anintermediate matrix R*, of size (r*, r*) with r*=m+1, and assuming thati, j∈N+, so that Eq. (13) is: $\begin{matrix}{{r*i},{j = \begin{matrix}{m_{i,j}{{\left( {0 < i \leq m} \right)\bigwedge\left( {0 < j \leq m} \right)}}} & (1) \\{m_{i,k}{{\left( {0 < i \leq m} \right)\bigwedge\left( {j = {m + 1}} \right)}}} & (2) \\{m_{1,j}{{\left( {i = {m + 1}} \right)\bigwedge\left( {0 < j \leq m} \right)}}} & (3) \\{0{{\left( {i = {m + 1}} \right)\bigwedge\left( {j = {m + 1}} \right)}\quad}} & (4)\end{matrix}}} & {{Eq}.\quad (13)}\end{matrix}$

[0228] In FIG. 15, expression (1) is a matrix portion 1502, expression(2) is a matrix portion 1504, expression (3) is a matrix portion 1506,and expression (4) is represented by remaining portions of the matrix1500 being set to the value “0.”

[0229] Analogous to matrix 1300 in FIG. 13, it is possible to expand Mby 1 row and 1 column at the index m+1, with expression (2) copyingcolumn k to column m+1 and expression (3) copying row 1 to row m+1, andfinally removing the rows l . . . k and the columns l . . . k from R.which represents all computational steps of expressions (1) to (4) inEq. (13) prior to the removal of approprate rows and columns in FIG. 15.A final step in the computation is to remove the rows m_(k) . . . m_(l)and the columns m_(k) . . . m_(l) from R. The resulting matrix is P ofsize (m+k−l, m+k−l).

[0230] As described above, the specialization operator 1200 in FIG. 12and the generalization operator 1400 in FIG. 14 serve to decrease andincrease, respectively, a level of abstraction of a workflow. As pointedout with respect to FIG. 10, these operations are inverses of oneanother. As discussed below, these inverse operations can be thought ofas one combined operation, referred to as “verticalization.” Usingverticalization, an operator can analyze a workflow and determine allfeasible groupings (linkings) of tasks within the workflow to formvarious workflow views, or, conversely, can examine a workflow view todetermine all feasible groupings of tasks into an underlying workflow.Similarly, rather than compute all possible groupings, an operator canselect possible groupings only for a particular task (or workflow viewtask).

[0231] In understanding the verticalization operation, it should beunderstood that the specialization operator 1200 in FIG. 12 replaces onevertex, v₁ in a first matrix M with n vertices from a second matrix N.Written above as Ms(l)N, it can thus be written more generically as:Ms(k, l)N with k=1. The generalization operator 1400 in FIG. 14,however, replaces l−k+1 vertices in M with one vertex. To represent agraph of one single vertex in a matrix requires a matrix of size (1,1).Therefore, the generalization operator 1400 could also be denoted asMg(k, l)N with [N]1×1, i.e., a 1×1 matrix.

[0232]FIG. 16 is an illustration of the verticalization operator 1600.Based one the above similarities between the specialization operator1200 and the generalization operator 1400, the verticalization operator1600, or “v,” can be written as: Mv(k, l)N. In this case, if k=1 andorder(N)>1, then the operator serves to specialize the matrix M, or makeM less abstract. For 1>k and order(N)=1, the operator serves togeneralize M, or make M more abstract.

[0233] More formally, if M is an (m,m) matrix, and N is an (n,n) matrix,then the k,l-verticalisation of M by N is defined such that Mv(k, l)N isa matrix R of size (m+k−l−1+n, m+k−1−l+n), such that the m_(k), . . .m_(l) columns of M and the m_(k), . . . m_(l) rows of M are replacedwith n1, n2, . . . , nn rows and columns of N. The elements of R=Mv(k,l)N are defined as follows in Eq. (14): $\begin{matrix}{r_{i,j} = \begin{matrix}{{m_{i,j}{{\left( {0 < i < k} \right)\bigwedge\left( {0 < j \leq k} \right)}}}} & (1) \\{{m_{i,{j + 1 + 1 - k - n}}{{\left( {0 < i < k} \right)\bigwedge\left( {{k + n} \leq j \leq r} \right)}}}} & (2) \\{{m_{i,{j + 1 + 1 - n},j}{{\left( {{k + n} \leq i \leq r} \right)\bigwedge\left( {0 < j \leq k} \right)}}}} & (3) \\{{m_{{i + 1 + 1 - k - n},{j + 1 + 1 - k - n}}{{\left( {{k + {n{.1}}} \leq i \leq r} \right)\bigwedge\left( {{k + n} \leq j \leq r} \right)}}}} & (4) \\{{n_{{i - k + 1},{j - k + 1}}{\left. {k \leq i < {n + k}} \right)\bigwedge\left( {k \leq j < {n + k}} \right)}}} & (5) \\{{m_{1,j}{{\left( {i = {k + {n{.1}}}} \right)\bigwedge\left( {1 \leq j \leq {k{.1}}} \right)}}}} & (6) \\{{0{{{{all}\quad {other}\quad i},j}}}} & (7)\end{matrix}} & {{Eq}.\quad (14)}\end{matrix}$

[0234] In FIG. 16, expression (1) is a matrix portion 1602, expression(2) is a matrix portion 1604, expression (3) is a matrix portion 1606,expression (4) is a matrix portion 1608, expression (5) is a matrixportion 1610, expression (6) is a matrix portion 1612, and expression(7) is represented by remaining portions of the verticalization operator1600 being set to the value “0.”

[0235] Functionally, expressions (1), (2), (3), and (4) copy M into R.Expression (5) enters N as a whole into R, and expression (6) connectsthe remaining vertices m_(i), that were adjacent from m_(l), to n_(l).

[0236] To derive the specialization operator from v, set k=1. Then, vscan be shown to be equivalent to the specialization operator s, asdefined in Eq. (10). Similarly, to derive the generalization operatorfrom v, set n=1 and N=[0] 1×1. Then, vg is can be shown to be equivalentto the generalization operator g as defined in Eq. (12).

[0237] Returning to FIG. 3, and considering the above description of theverticalization operator 1600, it can be seen that not all sub-groupingsof, for example, workflow K 302 are valid results of verticalization.For example, as shown in more detail below, there are only thirteensub-digraphs (i.e., structures or groupings) in workflow K 302 that arevalid to be generalized, and they are (1) {k1, k2} (2) {k1, k2, k3, k4,k5, k6, k7, k8}; (3) {k1, k2, k3, k4, k5, k6, k7, k8, k9}; (4) {k1, k2,k3, k4, k5, k6, k7, k8, k9, k10} (note that this grouping represents allof the tasks of workflow K 302, represented as the grouping “K”; (5){k2, k3, k4, k5, k6, k7, k8}; (6) {k2, k3, k4, k5, k6, k7, k8, k9}; (7){k2, k3, k4, k5, k6, k7, k8, k9, k10}; (8) {k3, k4, k5, k6, k7, k8}; (9){k3, k4, k5, k6, k7, k8, k9}; (10) {k3, k4, k5, k6, k7, k8, k9, k10};(11) {k4, k6}; (12) {k5, k7}; (13) {k9, k10}; (14)-(23) individual tasksk1-k10 of workflow K 302, which are regarded as trivial structures,where the set of trivial structures of workflow K 302 is denoted,“T_(K)”. This operation is denoted as identification of v-structures(“ivs”).

[0238]FIG. 17 is a block diagram illustrating a classification schemefor classifying workflow groups. In FIG. 17, a sample workflow L 1702includes a first task l1 1704, a second task l2 1706, a third task l31708, a fourth task l4 1710, a fifth task l5 1712, a sixth task l6 1714,a seventh task l7 1716, an eighth task l8 1718, a ninth task l9 1720, atenth task l10 1722, an eleventh task l11 1724, and a twelfth task l121726.

[0239] In classifying v-structures within a workflow, a structure K isconsidered to be an “atom” if it consists of at least 2 vertices andivs(K) results only in T_(K) and K itself A structure is considered a“molecule” if it consists of more than two vertices. If a structure is amolecule and ivs(K) results only in atoms and trivial structures, thenit is considered as first class molecule; while if ivs(K) results toother molecules, then K is considered to be second class molecule. Thus,in FIG. 17, grouping 12,13 1728, grouping 14,15 1730, grouping 18,191732, and grouping l10, l11 1734 are atoms. The grouping 1736 of tasksl1 1704-l6 1714 is a first class molecule, and the grouping 1738 oftasks l7 1716-l12 1726 is also a first class molecule. Finally, thegrouping 1740 of all tasks in workflow L 1702 is a second classmolecule.

[0240] In FIG. 3, the vertices {k3, . . . , k8}, i.e., tasks 314-324 inworkflow K 302, are represented by one vertex l2 332 in workflow L 304.This corresponds to grouping (8) in the above listing of verticalizablestructures of FIG. 3. The XOR-split (task k3 314) and join (task k8 324)and its embraced tasks ({k4, . . . , k7}, 316-322) are encapsulated.

[0241] FIGS. 18-23 provide further examples of how workflow k 302 can beverticalized (generalized). Some of the examples are valid examples ofverticalization, while others are invalid, as discussed individuallybelow.

[0242] In. FIG. 18, vertices {k3, . . . k10}, i.e., tasks 314-328 inworkflow K 302 are represented by one vertex l2 1802, which is grouping10 in the above listing of verticalizable structures. In FIG. 19, tasks310, 312, 314, 324, 326, and 328 are represented by correspondingindividual tasks 1902, 1904, 1906, 1908, 1910, and 1912, respectively.Tasks 316 and 320, are represented by one single vertex, 1914 (grouping11 above), and tasks 318 and 322 are represented by task 1916 (grouping12 above).

[0243] In FIG. 20A, tasks 310, 312, 314 a (which is an AND-split, ratherthan the XOR split 314 of FIG. 3), 316, and 318 are grouped into onetask l1 2002 a. Similarly, tasks 320, 322, 324 a (which is an AND join,as opposed to the XOR join 324 in FIG. 3), 326, and 328 are grouped intoone task l2 2004 a.

[0244] In FIG. 20A, the task l1 2002 a is ambiguous, because, withregards to the execution of workflow K 302, it would be possible fortask k7 322 to start while task k4 316 and, due to their dependency taskl1 2002 a, are still in progress, or even aborted. Since task k7 322 isrepresented by task l2 2004 a, task l2 2004 a would start before task l12002 a is completed. This course of events contradicts the “AND” natureof split 314 a, and violates fundamental rules in workflow, and istherefore invalid.

[0245] In FIG. 20B, tasks 310, 312, 314, 316, and 318 are grouped intoone task l1 2002 b. Similarly, tasks 320, 322, 324, 326, and 328 aregrouped into one task l2 2004 b.

[0246] In FIG. 20B, it would be necessary to analyze workflow K 302sufficiently to be sure that either tasks k4,6 316, 320 or tasks k5,7318, 322 are executed, which would not necessarily be true.

[0247] In FIG. 21, a task l1 2102 includes tasks 310, 312, and 314,while a task l2 2104 includes tasks 316, 318, 320, 322, 324, 326, and328. In FIG. 22, a task l1 2202 includes tasks 310, 312, and 314, a taskl2 2204 includes tasks 316 and 320, a task l3 2206 includes tasks 318and 322, and a task l4 2208 includes tasks 324, 326, and 328. In FIG.23, a task l1 2302 includes tasks 310, 312, and 314, a task l2 2304includes tasks 316, 318, 320, and 322, and a task 2306 includes tasks324, 326, and 328.

[0248] In FIGS. 21-23, the abstracted workflows do not guarantee thattheir underlying workflows will be properly executed, do not match anoperation of the verticalization operator 1600, and/or violate one ormore of the corresponding rules for verticalization set forth below.

[0249] One such rule that follows from the verticalization operator 1600is that when a vertex is being specialised, the specialising verticesshould act vertex-type-compliant. In other words, a set of vertices “L”that specialize a vertex (or vertices) “k” have to behave like the tasktype(s) of k. If k is of type AS, then L has to behave like andAND-split, which occurs when L has the identical number of outgoing arcsas k (which are all being used). Analogously, if k is of type XS, then Lhas to behave like an XOR-split, which occurs when it has the identicalnumber of outgoing arcs as k (where only one is being used). Analogousconsideration are applicable to the vertex-types of AND-joins andXOR-joins. Activity and sub-workflow have exactly one incoming and oneoutgoing arc.

[0250] This consideration also applies for the operation ofgeneralization. Here, a group of vertices L has to be formed such thatit behaves like one atomic vertex k.

[0251]FIG. 24 is a flowchart 2400 describing an algorithm to computev-structures. More specifically, the algorithm (referred to as “Kivs”)allows computation of all v-structures within a digraph K, therebyreturning V(Bn), i.e. the set of vertices for any identified v-structureBn. For the following considerations, νk and νl are two vertices in K.

[0252] In FIG. 24, it is first determined if v_(k) is not equal tov_(l), i.e., that at least two vertices are being considered (2402). Ifso, then it is determined whether a path between v_(k) and v_(l) exists(2404). If so, then it is determined whether the indegree (id) of v_(k)is less than or equal to one, and whether the outdegree (od) of v_(l) isless than or equal to one (2406). In other words, it is determinedwhether the first vertex vk of the group has no more than one incomingdependency (e.g., an activity task, but not an XOR join route task), andwhether the last vertex vl has no more than on outgoing dependency(e.g., an activity task, but no an AND split route task).

[0253] If this condition is met, then all vertices in the v_(k)-v_(l)path are determined and stored in a list “B” (2408). Afterwards, it isdetermined whether any vertex v_(i) in B is adjacent to any other vertexv_(j) not in B, and whether any vertex vi in B is incident from anyother vertex vj not in B (2410). In other words, no vertex in B shouldhave a dependency from or to another vertex not in B (other than theincoming/outgoing dependencies of v_(k), v_(l)). If there is such adependency, then the list B is invalid (2412). Otherwise, the list B isadded to a list “R” of valid structures (if the resulting structure isatomic, it may be replaced by a single vertex).

[0254] Afterwards (or if the indegree/outdegree of v_(k), v_(l) wasdetermined to be greater than one), then v_(l) is incremented (2418). Ifthis incrementing causes the order of v_(l) to be less than or equal tothe order of the entire digraph (workflow) k, then the above process isrepeated on the new path, beginning with a checking of theindegree/outdegree of the new path (2406).

[0255] Afterwards, then v_(k) is incremented (2420), and, if v_(k) isless than or equal to an order of the digraph (workflow) k, then theprocess repeats from the beginning (2402). Otherwise, the process isfinished, and the structures in list R are ordered according to theirorder (increasing); also, all first class molecules in R are replacedwith a single vertex (2424).

[0256] Using the above algorithm, in a sequence of length n, [(n²+n)/2]v-structures are obtained containing at least two vertices, or[(n2−n)/2] v-structures including n trivial structures. theidentification of v-structures will be a core functionality of a

[0257] Although the above algorithm is capable of calculating allv-structures in a workflow, such a computation may overly complicated orextensive for a particular need. Therefore, FIG. 25 presents a flowchart2500 for calculating a subset of v-structures desired by an operator.For example, an operator may interact with such an algorithm and provideinformation on which task (atoms) or set of tasks (molecules) should becombined into a virtual task. In such an interactive environment, it maynot be necessary or desirable to compute all possible structures thatcan be verticalised. Instead, the operator will generally select asingle task at a time that he or she thinks needs to be maintained asprivate. The tool would then make propositions on which adjacent atomsor molecules could be combined with the task in question. It should beunderstood that this approach typically reduces the computational timeneeded to compute required v-structures. This is due to the fact that,as referred to above, instead of computing all combinations, the toolwould only propose two: to the left of the task in question and to theright.

[0258] In FIG. 25, a transposition of a matrix K is denoted as K^(T). InK^(T), the direction of the arcs is reversed with respect to K, i.e. ifthere is an arc from vertex ν1 to vertex ν2 in K, then in K^(T), thereis an arc from ν2 to ν1. This allows us the use of the same algorithmthat computes along the direction of arcs in K to compute backwards withrespect to K, by using K^(T) instead. In the below discussion, thenotation “L” is a placeholder for K or K^(T), and/or is thecorresponding matrix representation of a workflow/digraph L. Thealgorithm described in FIG. 25 is referred to hereafter as “iavs,” where‘iavs’ stands for ‘identification of adjacent v-structures’.

[0259] In FIG. 25, νk, νl, and νk_(original) are vertices in L. Also,ν_(od0) is a vertex in L, which has outdegree zero, i.e., od(ν_(od0))=0,which is the final vertex in L. Calling K iavs(νk) will result in theclosest v-structure that includes vk, which follows after vk. InvokingK^(T) iavs(νk) results in the closest v-structure that includes vk,which is before vk with respect to K. B is a simple list that is able tostore the indexes of vertices in L. B is returned by the iavs algorithm.

[0260] The iavs algorithm begins with the assumptions thatv_(k(original))=v_(k), and that B is empty, and continues untilv_(k)=v_(odo) (i.e., the last vertex is reached), or until B isnonempty. If v_(k) is not V_(odo) or B is empty (2502), then it isdetermined whether vk is of type split or of type activity (2504). Ifv_(k) is of type split, then the algorithm proceeds in L along thedirection of the arcs in L until the next vertex of type join is found,whereupon the row number for the join vertex is stored in v_(l) (2506).If vk is of type activity, then the algorithm finds the vertex adjacentfrom v_(k), whereupon the row number for the adjacent vertex is storedin v_(l) (2508). To summarize, the algorithm finds a v_(k)-v_(l) path ina manner dependent upon the type of vertex originally analyzed.

[0261] Next, all the vertices in the v_(k(original)) path are found, andstored in a list B (2510). Then, the analysis described above isperformed, in which it is checked whether any vertex v_(i) in B isadjacent to, or incident from, a v_(j) that is not in B (2512). If thereare no such vertices, then the vertices in B are a valid v-structure,and the algorithm exits (2514). Otherwise, the vertices do not form avalid v-structure, and so the algorithm sets v_(k)=v_(l) (2516), andreturns to the beginning of the algorithm (2502).

[0262] The algorithm of flowchart 2500 may fail to identify v-structureswhen the chosen vertex, V_(k), is in a purely parallel structure. Forexample, if a split task defines two parallel activity tasks, which aresubsequently joined by a join task, then choosing one of the activitytasks will result in no v-structures. This is because proceeding fromthe chosen activity vertex (v_(k)) to the next vertex sets the join taskas the end vertex, v_(l). Since a join task, by definition, has adependency from the remaining parallel activity task, then it has avertex not within the v_(k)-v_(l) path (i.e., the other activity task).Checking K^(T) in this case (i.e., proceeding along the vertices in areverse direction) will not help find a v-structure, since a similarproblem is encountered at the split task (i.e., it has an outgoingdependency to a vertex not in the v_(k)-v_(l) path, meaning theremaining parallel activity task).

[0263]FIG. 26 is a flowchart 2600 for finding v-structures which is aback-up to flowchart 2500 of FIG. 25. This algorithm extends the “iavs”algorithm of flowchart 2500, and so is noted as “iavs_(e.)” In FIG. 26,when it is determined that K iavs(vk)=K^(T)iavs(vk)=EMPTY (2602), thenit is next determined whether v_(k) is either (1) of type Activity orSplit, or (2) neither (2604). If the task is one of activity or split,then the algorithm proceeds backwards in K until a (new) vertex of typesplit is found, which is then defined, and stored as, v_(k) (2606).Then, the algorithm of flowchart 2500, iavs, is invoked for this vk(2608). If a result of this algorithm, list B, is empty (2610), then thealgorithm returns to look for another activity/split task (2602). If Bis found to be a valid v-structure, then the algorithm exits (2612).

[0264] If v_(k) is neither an activity or split task, then the algorithmproceeds along K until the next following join task is found (2614). Inthis case, then the iavs algorithm of flowchart 2500 is invoked asB=K^(T)iavs(v_(k)), i.e., the algorithm runs in a reverse direction of K(2616). Again, if a result of this algorithm, list B, is empty (2610),then the algorithm returns to look for another activity/split task(2602). If B is found to be a valid v-structure, then the algorithmexits (2612).

[0265]FIG. 27A is an first example of a digraph (workflow) 2700, andFIG. 27B is a table listing adjacent v-structures for each vertex (node)of the digraph 2700.

[0266] Digraph 2700 includes an activity task s1 2702, a split task s22704, a split task s3 2706, an activity task s4 2708, an activity tasks5 2710, a join task s6 2712, an activity task s7 2714, a join task s82716, an activity task s9 2718, an activity task s10 2720, a join tasks11 2722, an activity task s12 2724, and an activity task s13 2726.

[0267] The table of FIG. 27B lists all adjacent v-structures for theabove-listed workflows. In this case, for example, all of tasks s22704-s12 2724 have only one possible v-structure, which is the structurethat includes all tasks from s2 2704 to s12 2724, inclusive. This meansthat these tasks could be grouped together into a single abstractedworkflow view task for presentation to outside parties and/or use in theabove-described three-tier workflow of Section I.

[0268]FIG. 28A is a first example of a digraph (workflow) 2800, and FIG.28B is a table listing adjacent v-structures for each vertex (node) ofthe digraph 2800.

[0269] Digraph 2800 includes an activity task s1 2802, a split task s22804, an activity task s3 2806, an activity task s4 2808, an activitytask s5 2810, an activity task s6 2812, an activity task s7 2814, a jointask s8 2816, a join task s9 2818, an activity task s10 2820, anactivity task s11 2822, a split task s12 2824, an activity task s132826, an activity task s14 2828, a join task s15 2830, a split task s162832, an activity task s17 2834, an activity task s18 2836, a join tasks19 2838, an activity task s20 2840, an activity task s21 2842, and anactivity task s22 2844.

[0270] The table of FIG. 28B lists all adjacent v-structures for theabove-listed workflows. For example, task s21 2842 has two possibleverticalizations, i.e., the grouping of task s20 2840 and task s21 2842,or the grouping of task s21 2842 and task s22 2844. Again, this meansthat these two task groupings could be joined into either of the twoabstracted workflow view tasks for presentation to outside partiesand/or use in the above-described three-tier workflow of Section I.

[0271]FIG. 29 is a first screenshot 2900 of a tool for identifyingv-structures. FIG. 29 includes a first portion 2900A, and a secondportion, 2900B. In portion 2900A, a plurality of tasks in a workflow arerepresented as a node s1 2902, a node s2, 2904, a node s3 2906, a nodes4 2908, a node s5 2910, a node s6 2912, a node s7 2914, a node s8 2916,a node s9 2918, and a node s10 2920.

[0272] In the second portion 2900B, the tool presents a user, in section2921, with an ability to enter a number of a vertex to verticalize, inwhich a user has selected vertex 9, representing node s9 2918. Insection 2922, the tool presents the user with a first option forverticalization, and presents a second option in section 2924. In thefirst option, verticalization would result in joining all nodes from s12902 to s9 2918 into a workflow view node. The second option wouldresult in joining only nodes s9 2918 and s10 2920 into a workflow viewnode.

[0273]FIG. 30 is a second screenshot 3000 of a tool for identifyingv-structures. In FIG. 30, the user has selected option 2 in section3002, and the tool has responded by joining node s9 2918 and node s102920 into a single node s11 3004.

[0274]FIG. 31 is a third screenshot 3100 of a tool for identifyingv-structures. In FIG. 31, in section 3102, a user has selected vertex 3,representing node s3 2906, for verticalization. In section 3104, thetool informs the user that, to the left of node s3 2906, there are noavailable option for verticalizing vertex 3. This is because node s32906 is a split task, and verticalizing this node into a workflow viewwithout a corresponding join task would violate the rules forverticalization set forth above.

[0275] In section 3106, the tool presents the user with a second optionfor verticalizing node s3 2906, i.e., the inclusion of nodes betweennode s3 2906 and node s8 2916, inclusive.

[0276]FIG. 32 is a fourth screenshot 3200 of a tool for identifyingv-structures. In FIG. 32, the user has selected, in a section 3202,option 2 (presented in section 3106). As a result, a new node s12 3204is included in the workflow at the left. The user then selects a newvertex in section 3206, and is presented with a first option 3208 and asecond option 3210 for verticalization.

[0277] The above techniques represent different ways to alter anabstraction level of one or more tasks within a workflow. increasing anabstraction level of a workflow can be performed by the generalizationoperation defined above, while the abstraction level can be decreasedthrough the operation of specialization. An abstracted workflow can beused simply to maintain confidential information about the abstractingparty, and/or can be used in conjunction with the three-tier workflowmodel described in Section I.

Section III

[0278] In Section I, a three-tier workflow model is described whichallows collaborating parties to take their respective private workflows,generate abstracted workflow views, and carry out a collaborativeworkflow using the workflow view. Section II describes techniques forvarying an abstraction level of a workflow, and these techniques can beused to change workflows into workflow views, and vice-versa.

[0279] Section III describes ways to join tasks from multiple workflowsinto a single workflow, and/or to separate a single workflow intomultiple sub-workflows. These techniques can be used, for example, toform workflows and/or workflow views into a collaborative workflow foruse in the three-tier workflow model of Section I, or can be used todivide a collaborative workflow into individual workflows, which canthen be assigned to individual parties within the coalition forenactment.

[0280] Returning to FIG. 10, the operation of combining multipleworkflows into a single workflow may be implemented using the“expansion” operation 1006, while the operation of dividing workflowsinto parts for, for example, assignment to multiple parties forimplementation, may be practiced using the “reduction” operation 1008.The operations of expansion and reduction are discussed in more detailbelow.

[0281] In discussing the various techniques and operation justmentioned, the discussion below differentiates between two types ofworkflows: “outsourced” workflows and “distributed” workflows. Theseworkflow types, and their differences, are discussed with respect toFIGS. 33 and 34.

[0282]FIG. 33 is a block diagram of an outsourced workflow 3300.Specifically, the workflow is enacted by a partner A 3302 and a partnerB 3304, and includes a task t11 3306, t12 3308, t13 3310, t14 3312, t153314, t16 3316, and t17 3318. In workflow 3300, the task t12 3308 isoutsourced from partner B 3304 to partner A 3302 as task t13 3310. Also,the task t14 3312 is outsourced from partner B to partner A 3302 as taskt15 3314 and task t16 3316.

[0283] In short, in FIG. 33, it can be said that one or more activitiesor sub-workflows of an existing private workflow are implemented outsideof the scope of the workflow by an external task or workflow. Theexisting activities or sub-workflows in the private workflow areplaceholders for external activities or sub-workflows. In FIG. 33, taskst12 3308 and t14 3312, as just explained, are proxies for partner A'stasks t13 3310, t15 3314, and t16 3316 that implement them. Tasks t123308 and t14 3314 communicate with partner A's implementing tasks duringtheir lifecycle. This is transparent for the workflow management systemthat performs the workflow of partner B 3304, because the outsourcingacts exactly the same as a performing agent.

[0284] Outsourced workflows can be considered to be analogous toworkflows and workflow views, in that a workflow outsources its tasks tothe workflow view.

[0285]FIG. 34 is a block diagram of a distributed workflow 3400.Specifically, the workflow is enacted by the partner A 3302 and/or thepartner B 3304, and includes a task t1 3402, t2 3404, t3 3406, t4 3408,t5 3410, and t6 3412, as shown. In FIG. 34, then, all activities orsub-workflows of a party's private workflow are implemented inside thescope of the private workflow. The existing private workflow isaugmented by one or more activities or sub-workflows of an externalworkflow (i.e., belonging to another party). In FIG. 34, the tasks ofpartner A 3302 and the tasks of partner B 3304 are assumed to bepre-existing, and so they are complete in a sense that their respectivetasks are linked by dependencies.

[0286]FIG. 35 is an expanded block diagram of the distributed workflow3400. FIG. 35 illustrates the route tasks and/or dependencies used toensure order preservation and coordination of the tasks of workflow3400. Such route tasks are needed to synchronize the workflows ofpartner A 3302 and partner B 3304.

[0287] In FIG. 35, an AND-split task 3502 splits the path of workflow3400, sending one flow to task t2 2404, while the other flow waits for areturn at an AND-join task 3504. When task t2 3404 is completed, anAND-split task 3506 splits the resultant flow into two again, sendingone flow back to the AND-join task 3504. Having ensured that task t23404 is completed in this fashion, task t3 3406 proceeds. Uponfinishing, task t3 3406 outputs to an AND-split task 3510, which sends afirst flow back to the AND-join 3508, allowing tasks t4 3408 and t5 3410to proceed, and sends a second flow to a final AND-join task 3512, whichwaits until task t5 3410 is complete before allowing task t6 3412 tobegin.

[0288] Thus, the various route tasks synchronize the flow of workbetween partner A 3302 and partner B 3304, such that each outgoingdependency requires the emitting task to add an AND-split, while eachincoming dependency requires the receiving task to add an AND-join. Inthis way, both the synchronization (route) tasks and the dependenciesbetween the workflows of Partner A 3302 and partner B 3402 may bemanaged.

[0289] Considering task t1 3402, task t3 3406, and task t6 3412 to afirst workflow (i.e., associated with partner B 3304), and task t2 3404,task t4 3408, and task 3410 to be a second workflow (i.e., associatedwith partner A 3302), then the operation of expansion can be seen toinclude the process of deciding how and where to add synchronizing(route) tasks to obtain a properly-ordered collaborative workflow.

[0290] Generally speaking, then, expansion combines two or moreworkflows from the same level, so that one or more vertices in one isaugmented by one or more vertices in the other through parallelism orsequentialism. The process of expansion requires the augmentation of theexisting workflows by coordinating and synchronizing tasks, i.e.AND-splits and AND-joins, as illustrated in FIG. 35.

[0291] In FIG. 35, a sequential, or series, combination of workflowtasks is illustrated. As shown, this combination took into considerationthe integrity of the involved digraphs (workflows). That is, thedigraphs were not decomposed into smaller, disconnected subsets. As alsoshown, generally speaking, a sequential combination of vertices mayhelpfully utilize the introduction of an AND-split after the firstvertex in the sequence, an AND-join before the second vertex (not shownin Figure, because task t2 3404 is the very first vertex in the workflowof partner A 3302), an AND-split after the second vertex and an AND-joinbefore the third vertex, and so on.

[0292]FIG. 36 is a block diagram of a parallel combination of multipleworkflows. As just discussed, FIG. 35 dealt with a sequentialcombination of workflows. In FIG. 36, a first diagraph (workflow) Kincludes a task k1 3602, a task k2 3604, and a task k3 3606, and isassumed to be, by itself, a simple first, second, third sequence oftasks. A second digraph L includes a task l1 3608, a task l2 3610, and atask l3 3612, and is also assumed to be, by itself, a simple linear listof tasks. Also in FIG. 36, as shown, tasks l1 and l2, together, are inparallel with task k2.

[0293] In FIG. 37, an AND-split k4 3702 is added before the task to beparallelised in a first one of the digraphs (i.e., here, task k2 3604 indigraph K), and an AND-join l4 3704 is added before (l4) before the taskto be parallelised in a second one of the digraphs (i.e., here, task l13608 in digraph L). As noted above with respect to FIG. 35, the AND-joinl4 3704 is not completely necessary, since there is no other tasks to bejoined to task l1 3608 (it being the first task in digraph L), however,the AND-join l4 3704 is shown here for completeness.

[0294] Further in FIG. 37, an AND-split l5 3706 is added after thestructure (i.e., task l1 3608 and task l2 3610) to be parallelised inthe second one of the digraphs (i.e., L) that does not continue thepath, and an AND-join k5 3708 after the structure (i.e., task k2 3604)to be parallelised in the first one of the digraphs (i.e., K). Finally,an AND-join l6 3710 is added after the task k3 3606 and before the finaltask of the joint digraph (workflow), task l3 2612.

[0295] In this discussion of an expansion operation, describing examplesof formal techniques for performing expansion, it is assumed thatcombined structures in two digraphs K and L, such as the digraphsdiscussed with respect to FIG. 37, generally satisfy the conditions ofverticaliseable structures discussed above in Section II.

[0296] The discussion of FIGS. 35 and 37 centered around sequential andparallel structures, respectively. A collaborative workflow willtypically include multiple sequential and parallel structures, and so ageneral solution for combining workflows and maintaining an order ofexecution therefore requires an approach that takes into account aholistic view of structures that are adjacent, e.g. when a parallelstructure is formed after a sequential structure, rather than anisolated expansion of single structures.

[0297]FIG. 38 is an example of a first matrix 3800 resulting from afirst expansion operation. The first expansion operation may referred toherein as the “liaise matrix operator.” Using the first expansionoperation, two matrices M and N, which represent their adjacent digraphsM and N, are copied into the same, single matrix R (i.e., matrix 3800),without connecting any vertex from M to N, or vice versa. The firstexpansion operation is described by Eq. (15), in which M is an (m,m)matrix and N is an (n,n) matrix. R is a matrix of size (r, r) withr=m+n. If i is a row index and j is a column index, as above, and withi, j∈N+, and 1≦i≦r and 1≦j≦r, then the first expansion operation definesthe “liaison” of M by N, denoted as R=MIN as follows: $\begin{matrix}{r_{i,j} = \begin{matrix}{{m_{i,j}{{\left( {1 \leq i \leq m} \right)\bigwedge\left( {1 \leq j \leq m} \right)}}}} & (1) \\{{n_{{i - m},{j - m}}{{\left( {m < i \leq r} \right)\bigwedge\left( {m < j \leq} \right)}}}} & (2) \\{{0{{{{all}\quad {other}\quad i},j}}}} & (3)\end{matrix}} & {{Eq}.\quad (15)}\end{matrix}$

[0298] In FIG. 38, expression (1) is a matrix portion 3802, expression(2) is a matrix portion 3804, and expression (3) is represented byremaining portions 3806 of the matrix 3800 being set to the value “0.”In Eq. (15), expression (1) copies M into R, while expression (2) copiesN into R.

[0299]FIG. 39 is an example of a second matrix 3900 resulting from asecond expansion operation. The second expansion operation may referredto herein as the “link vertices operator.” Using the second expansionoperation, values of the matrix R (i.e., matrix 3900) are modified toreflect the building (or removal) of arcs (i.e., dependencies) betweenvertices.

[0300] The second expansion operation, when adding new links, does notgenerally consider insertion of any additional coordinating vertices. Asa result, the resulting matrix (i.e., modification of R) may representan invalid workflow M, since regular tasks now also have to act ascoordination tasks.

[0301] The second expansion operation is represented by Eq. (16), inwhich R is a matrix of size (r, r) with r=m, and the operationestablishes or removes an arc from vertex “k” to vertex “l” in M. In thecontext of Eq. (16), “k” is an index of a row in M, and “l” is an indexof a column in M, with k, l∈N+, 1≦k and 1≦m. Also, z is a discriminator,such that z=1 expresses that an arc is established, or when z=0, that anarc is being removed.

[0302] Thus, the k,l-linking of M, denoted as R=M lv (k, l) z can bedefined in Eq. (16) as:

r _(i,j) =m _(i,j)|(1≦i≦m){circumflex over (0)} (1≦j≦m){circumflex over(0)} (i≠k){circumflex over (0)} (j≠1) (1)

z|(i=k){circumflex over ( )}(j=1) (2)  Eq. (16)

[0303] In FIG. 39, expression (1) is a matrix portion 3902, andexpression (2) is a matrix portion 3904. Expression (1) copies allelements of M into R, except at the index k, l, while expression (2)establishes or removes the link from k to l.

[0304]FIG. 40 is an example of a third matrix 4000 resulting from athird expansion operation. The third expansion operation may referred toherein as the “insert vertex before operator.” The third expansionoperation inserts a new vertex ν_(n) before a given vertex ν_(g), buildsan arc from ν_(n) to ν_(g), and assigns all incoming arcs from ν_(g) toν_(n). This third expansion operation reconciles M by adding a vertex oftype AND-join before every vertex of type Activity that has more thanone incoming arc.

[0305] The third expansion operation is represented by Eq. (17), inwhich matrix R (i.e., matrix 4000) is now of size (r, r), but withr=m+1. In this context, “k” is now the index of a row in M, with k∈N+and1≦k≦m. With these notations, the “k-insertionBefore” of M, abbreviatedas R=M ivb (k) is shown in Eq. (17) as: $\begin{matrix}{r_{i,j} = \begin{matrix}{{m_{i,j}{\left. {\left( {1 \leq i \leq m} \right)\bigwedge\left( {1 \leq j \leq m} \right)} \right)\bigwedge\left( {j \neq k} \right)}}} & (1) \\{{m_{i,k}{{\left( {1 \leq i \leq m} \right)\bigwedge\left( {j = r} \right)}}}} & (2) \\{{1{{\left( {i = r} \right)\bigwedge\left( {j = k} \right)}}}} & (3) \\{{0{{{{all}\quad {other}\quad i},j}}}} & (4)\end{matrix}} & {{Eq}.\quad (17)}\end{matrix}$

[0306] In FIG. 40, expression (1) is a matrix portion 4002, expression(2) is a matrix portion 4004, expression (3) is a matrix portion 4006,and expression (4) is represented by remaining portions 4008 of thematrix 4000 being set to the value “0.” In Eq. (17), expression (1)copies all elements of M into R, except for column k, while expression(2) moves the incoming arcs from v_(k) to v_(r). Expression (3) connectsv_(r) to v_(k).

[0307]FIG. 41 is an example of a fourth matrix 4100 resulting from afourth expansion operation. The fourth expansion operation may referredto herein as the “insert vertex after operator.” This operation insertsa new vertex νn after a given vertex νg, builds an arc from νg to νn,and assigns all outgoing arcs from νg to νn. In other words, the fourthexpansion operation reconciles the matrix M by adding a vertex of typeAND-split after every vertex of type Activity that has more than oneoutgoing arc.

[0308] The fourth expansion operation is represented by Eq. (18), inwhich matrix R (i.e., matrix 4100) is a matrix of size (r, r) withr=m+1. Here, “k” represents an index of a row in M, with k∈N+, and1≦k≦m. With these notations, the “k-insertionAfter” of M, abbreviated asR=M iva (k), is defined by Eq. (18) as $\begin{matrix}{r_{i,j} = \begin{matrix}{{m_{i,j}{\left. {\left( {1 \leq i \leq m} \right)\bigwedge\left( {1 \leq j \leq m} \right)} \right)\bigwedge\left( {i \neq k} \right)}}} & (1) \\{{m_{k,j}{{\left( {i = r} \right)\bigwedge\left( {1 \leq j \leq m} \right)}}}} & (2) \\{{1{{\left( {i = k} \right)\bigwedge\left( {j = 0} \right)}}}} & (3) \\{{0{{{{all}\quad {other}\quad i},j}}}} & (4)\end{matrix}} & {{Eq}.\quad (18)}\end{matrix}$

[0309] In FIG. 41, expression (1) is a matrix portion 4102, expression(2) is a matrix portion 4104, expression (3) is a matrix portion 4106,and expression (4) is represented by remaining portions 4108 of thematrix 4100 being set to the value “0.” In Eq. (18), expression (1)copies all elements of M into R, except for row k, while expression (2)moves the outgoing arcs from vk to νr, and expression (3) connects vk toνr.

[0310] In the above, all four of the expansion operations may beperformed electronically. Alternatively, one or more of the operationsmay be performed manually. For example, the first, third and fourthexpansion operations may be conducted electronically, while a humanoperator contributes to the second expansion operation by providinginput about a desired order of a (collaborative) workflow. For example,the operator may define connection rules in an abstract model, such as acoalition workflow in the above three-tier workflow model of Section I.

[0311] The following discussion provides an example of an expansionoperation using the above operations. More specifically, the example isperformed on the workflow(s) described above with respect to FIGS. 36and 37, in which a first workflow K has three sequential tasks k1 3602,k2 3604, and k3 3606, and a workflow L has three sequential tasks l13608, l2 3610, and l3 3612. The tasks are to be joined in the mannerdescribed in FIG. 37.

[0312] In this case, a first expansion operation includes the liaisematrix operator defined above as R=KlL. In other words, K and L arejoined into a new matrix R. The second expansion operation is a seriesof uses of the link vertices operation, lv, to modify the new matrix R.Specifically, R_=Rlv(k1, l1) 1, followed by R2_=R_lv(l2, k3) 1, followedby R3_=R2_lv(k3, l3) l. In these operations, the tasks are linked asdescribed, without the benefit of route tasks.

[0313] Next, the third expansion operation inserts vertices beforetasks, as needed (i.e., inserts the AND-join task k5 3708 and theAND-join task l6 3710), with the operations R4_=R3_ivb(k3), followed byR5_=R4_ivb(l3).

[0314] Finally, the fourth expansion operation inserts vertices aftertasks, as needed (i.e., inserts the AND-split task k4 3702 and theAND-split task 3706), with the operations R6_=R5_iva(k1), followed byR7_=R6_iva(l2).

[0315] As discussed above, the inverse of the expansion operation is thereduction operation. Reduction allows a joined workflow to be separatedinto sub-parts, so that individual members of the coalition mayimplement them, for example, in their respective workflow views.Formally, reduction separates one or more vertices from a workflow, andre-links the dependencies that formerly referred to/from a vertex to thevertex's neighbors. In the following notation, e(K) may be consideredthe expansion of a workflow K, and r(K) is the reduction of K. Since thetwo operations are inverses of one another, then, for each expansion ofK there is a reduction such that r(e(K))=K and vice versa e(r(K))=K.

[0316] The reduction operation is discussed below with reference to amatrix M of an associated digraph of order “m,” which is “reduced”(decomposed) into a set of smaller digraphs R_(g) with {g∈N+|2≦g≦m}.

[0317] The following two condition should be satisfied: first, R_(g) isassumed to be a valid digraph, and, second, that vertices from M can bereduced into the same R_(g) only when these vertices are connected,i.e., when there is a walk between these vertices, or when they are partof a v-structure.

[0318]FIG. 42 is a sample digraph used to illustrate the operation ofreduction. FIGS. 42A-42D are digraphs illustrating valid and invalidresults of a reduction operation. In FIG. 42, a digraph M 4200 includesa split task m1 4202, a split task m2 4204, an activity task m3 4206, anactivity task m4 4208, a join task m5 4210, a join task m6 4212, anactivity task m7 4214, and an activity task m8 4216.

[0319]FIG. 42A illustrates a valid reduction of digraph M 4200.Reduction, as discussed in more detail below, involves the removal ofroute tasks that become obsolete as a result of the reduction operation.In FIG. 42A, a first reduced digraph R1 4218 includes the split task m24204, the activity task m3 4206, the activity task m4 4208, and the jointask m5 4210, while a second reduced digraph R2 4220 includes theactivity task m8 4216 and the activity task m7 4214.

[0320]FIG. 42B illustrates a valid reduction of digraph M 4200. In FIG.42B, a first reduced digraphs R1 4222 includes the activity task m3 4206and the activity task m7 4214, while the second reduced digraph R2 4224includes the activity task m4 4208, and the third reduced digraph R34226 includes the activity task m8 4216.

[0321]FIG. 42C illustrates a valid reduction of digraph M 4200. In FIG.42C, a first reduced digraph R1 4228 includes the split task m1 4202,the activity task m4 4208, the activity task m8 4216, and the join taskm6 4212, while the second reduced digraph R2 4230 includes the activitytask m3 4206 and the activity task m7 4214.

[0322]FIG. 42D illustrates an invalid reduction of digraph M 4200. InFIG. 42D, a first reduced digraph R1 4232 includes the activity task m34206 and the activity task m4 4208, while the second reduced digraph R2includes the activity task m8 4216 and the activity task m7 4214.

[0323] In FIGS. 42A-42C, all reduced digraphs adhere to the twoconditions set forth above; i.e., they are valid digraphs, and areeither connected and/or part of a valid v-structure. In contrast, in theinvalidly-reduced digraph R1 4232 of FIG. 42D, activity task m3 4206 andactivity task m4 4208 violate the condition of connectivity, since thereis no dependency therebetween.

[0324]FIG. 43 is a matrix 4300 that is an example of a reductionoperator. Matrix 4300 is described by Eq. (19), in which M is an (m,m)matrix, and R is a matrix of size (r,r,), with r=m−1. If i is a rowindex and j is a column index, and assuming i, j∈N+and 1≦i, j≦r, thenthe “k-reduction of M” is denoted as R=Mr (k), as described in Eq. (19):$\begin{matrix}{r_{i,j} = \begin{matrix}{\left( {m_{i,j}{\left. {\left( {1 \leq i < k} \right)\bigwedge\left( {1 \leq j < k} \right)} \right)\bigvee m_{k,j}}{{\left( {m_{k,j} = 1} \right)\bigwedge\left( {m_{i,k} = 1} \right)}}} \right.} & (1) \\{\left( {m_{i,{j + 1}}{\left. {\left( {1 \leq i < k} \right)\bigwedge\left( {k \leq j \leq r} \right)} \right)\bigvee m_{k,{j + 1}}}{{\left( {m_{k,{j + 1}} = 1} \right)\bigwedge\left( {m_{i,k} = 1} \right)}}} \right.} & (2) \\{\left( {m_{{i + 1},j}{\left. {\left( {k \leq i \leq r} \right)\bigwedge\left( {1 \leq j < k} \right)} \right)\bigvee m_{k,j}}{{\left( {m_{k,j} = 1} \right)\bigwedge\left( {m_{{i + 1},k} = 1} \right)}}} \right.} & (3) \\{\left( {m_{{i + 1},{j + l}}{\left. {\left( {k \leq i \leq r} \right)\bigwedge\left( {k \leq j \leq r} \right)} \right)\bigvee m_{k,{j + 1}}}{{\left( {m_{k,{j + 1}} = 1} \right)\bigwedge\left( {m_{{i + 1},k} = 1} \right)}}} \right.} & (4)\end{matrix}} & {{Eq},\quad (19)}\end{matrix}$

[0325] In FIG. 43, expression (1) is a matrix portion 4302, expression(2) is a matrix portion 4304, expression (3) is a matrix portion 4306,and expression (4) is a matrix portion 4308. Expressions (1) to (4) copyelements from M into R, omitting the elements from row and column k inM. An OR-combination with m_(k,j) (m_(k,j) respectively, not shown inFIG. 43) connects the arcs that were adjacent to vertex Vk in M to theneighbors of vk. The logic in the above operation is such that whenm_(i,k)=1, then this means that v_(i) precedes v_(k). Similarly, whenm_(k,j)=1, then this means that v_(j) follows v_(k).

[0326] By then setting m_(i,j)=m_(i,k)=m_(k,j)=1 in R, this connectsv_(i to v) _(k), which is performed in Eq. (19) under consideration ofthe respective ranges of the indexes i and j.

[0327] Thus, the approach of Eq. (19) is to connect all arcs that areadjacent to the vertex vk to the neighbors of v_(k), and then delete vkand its connecting arcs from M. To obtain the various reduction digraphsRx from M (e.g., see FIG. 42) the operation of reduction is repeatedlyapplied to M, in order to delete all vertices that are considered to notbe elements of Rx.

[0328] Applying Eq. (19) to FIG. 42A above, for example, digraph R14218is computed as R1=Mr(1) r(8) r(6) r(7), while R2 4220 is computed asR2=Mr(1) r(2) r(3) r(4) r(5) r(6). In FIG. 42B, digraph R1 4222 iscomputed as R1=Mr(1) r(2) r(4) r(5) r(6) r(8), while R2 4224 is computedas R2=Mr(1) r(2) r(3) r(5) r(6) r(7) r(8), and R3 4226 is computed asR3=Mr(1) r(2) r(3) r(4) r(5) r(6) r(7).

[0329] In conclusion, Section III above presents a variety of techniquesto combine multiple workflows into a single workflow, as well astechniques to extract multiple workflows from a single workflow. Thetechniques can be used, for example, to combine workflows from multiplepartners wishing to work together. More specifically, the techniques canbe used in the three-tier workflow model of Section I, to combine aplurality of workflow views of partners into a single collaborativeworkflow, and to divide the collaborative workflows intosub-subworkflows, for assignment to members of the coalition.

Section IV

[0330] Section I above describes a three-tier workflow model forcollaborative workflows. Sections II and III describe techniques which,among other uses, are useful for implementing the three-tier workflowmodel of FIG. 1. Section IV presents a description of why these modelsand techniques are useful and/or necessary in implementing collaborativeworkflows, as well as a taxonomy for describing collaborative workflows.

[0331] In considering collaborative workflows, it is possible toconclude that such workflows include only simple nested interactions.For example, workflow A starts workflow B; workflow A waits until Bcompletes, and then commences its own operation.

[0332] A second hypothesis is that collaborative business processinteractions may be as complex as interactions within a single workflow.For example, workflow A may interact with workflow B (and vice versa)during multiple occasions, and/or perhaps a third or more workflows areinvolved. The second hypothesis is assumed in Sections I, II, and IIIabove.

[0333] In considering this hypothesis, various market models aredescribed below. For example, Electronic Marketplaces, orE-Marketplaces, are increasingly the medium of choice when businessesinteract with each other, with their partners and customers. Unlikeclassical peer-to-peer trade between businesses, E-Marketplaces act asmediators between trading partners. Vertical marketplaces bring togetherdomain-specific demand and supply, while horizontal E-Marketplaces spanmultiple domains, thus offering a wider spectrum of goods, althoughusually not as specific.

[0334] One thing to consider about collaborative workflows is theirinteraction granularity. Generally, simple, coarse-grained interactionswill have a simple realisation, while complex, fine-grained interactionsrequire a closer look and (possibly) a more sophisticated solution.

[0335]FIG. 44 is a block diagram of three aspects of workflowinteroperability. In FIG. 44, a first workflow aspect is a chainedenactment 4402, in which a workflow instance 4404 of workflow K 4406enacted on workflow Engine A triggers the creation and enactment of aworkflow instance 4408 of workflow L 4410 on Workflow Engine B, and,once enacted, both workflow instances carry on their operation (i.e.,enact a task 4412 and a task 4414) without further synchronisation.

[0336] A second workflow aspect is a synchronous enactment 4416, inwhich a workflow instance 4418 triggers the creation and enactment of aworkflow instance 4420, and then waits for its completion/termination(e.g., completion of a task 4422 and a task 4424) before it resumes itsown operation (i.e., finishes a task 4426 and a task 4428).

[0337] A third workflow aspect is a parallel invocation 4430, in whichtwo workflow engines simultaneously execute work-flow instances 4432 and4434 of workflows 4406 and 4410, respectively. The workflow definitionsspecify a point (i.e., tasks 4436 and 4438) at which the workflowinstances rendezvous. In other words, one workflow engine waits for theother to achieve the rendezvous point. There is interchange ofinformation between the workflow engines at this point, and then theworkflows continue in tasks 4440 and 4442.

[0338] These three aspects of workflow interoperability can bedistinguished according to their requirement(s) to enact new workflowinstances, as is the case in the chained enactment 4402 and the nestedenactment 4412, or to invoke existing workflow instances as in the caseof the parallel invocation 4430.

[0339] Another categorization is according to the return control flow.That is, while the chained enactment 4402 generally includes only auni-directional communication; the nested enactment 4416 and theparallel invocation 4430 are bi-directional, and therefore include areturn control flow to the invoker.

[0340] From these interoperability aspects, the parallel-synchronisedmodel is of particular interest, because it requires a mechanism ofidentifying the communication partner (which is a workflow instance)without creating it.

[0341] Further details regarding a taxonomy of collaborative workflowsinclude the following terminology. First, the term enactment is used tomean that a new workflow instance is created from an existing workflowschema, while the term invocation refers to communication with anexisting workflow instance. The differentiation is significant, as thefirst requires information about an existing workflow schema, while thelatter requires precise information on which particular instance out ofa possibly large set of instances that have been instantiated from aworkflow schema is the information recipient.

[0342] A request-to-task ratio (r_(t)) quantifies how many request arenecessary to commence a task. Thus, _(rt) is defined as:r_(t)=(n_(r)/n_(t)), with n_(r) being the number of requests and n_(t)the number of tasks. There may be one request to perform a task(r_(t)=1), or multiple requests (r_(t)>1). For r_(t)<1, a task isexecuted without request, i.e. in the case of an automatically scheduledtasks. Thus, rt can be considered a message correlation indicator fortask execution.

[0343] If a request is followed by a response then this is considered atwo-way communication (request with response). If the request is notfollowed by a response, then this is one-way communication (requestwithout response). These expressions do not express when the responseoccurs, i.e. immediately or in the far future.

[0344] Interdependency is considered from the perspective of a task in aworkflow. In a synchronous communication, the sending task waits for thereceiving task to return with a result before it commences operation,which is called task-synchronous. In asynchronous communication, incontrast, the sending task continues its operation while the receivingtask operates, which is called task-asynchronous. In the context ofworkflows, once a workflow communicates with another workflow andreceives a response for which it has to wait at some point in time, thenthis is considered as workflow-synchronous communication. If theworkflow does not receive a response, or it does not have to wait forit, then this is considered a workflow-asynchronous communication.

[0345] With respect to ownership of messages, when a request fromrequester A to receiver B is followed by a response from B to A, then Bacts on its own behalf. B is considered the owner of the response, andacts on its own behalf. If, however B replies to A through C, then Bdelegates its response to C. Then, C is a delegate of the response. Thedistinction is relevant, as C has to have some knowledge about A withouthaving had prior interaction.

[0346] A request-to-response ratio (r_(t)) quantifies a number ofrequests in relation to the responses that result from this request.This parameter is defined as r_(r)=(n_(r)/n_(s)), with n_(r) being thenumber of requests, and n_(s) being the number of responses. Forr_(r)=1, one request is followed by one response. For r_(r)<1, onerequest is followed by multiple responses. For r_(r)>1, multiple requestare followed by one response. In both of the latter cases, the multiplemessages will typically be correlated, possibly across multiple sendingor receiving tasks. Not correlating them may result in multipleexecution of the following task. When no response is received, r_(r) isnot defined.

[0347] The above terminology is used below in various examples,referring to workflow instances K, L, and M. In a first example, aninvocation from K to L is followed by a response from L to K. Thisinterdependency is task-synchronous; L is the owner of the response to Kand r_(t)=1 and r_(r)=1.

[0348] In a second example, K invokes L synchronously. L invokes Masynchronously, and L and M reply back to K. Thus, L delegated itsresponse to M, while preserving the right to act on its own behalf. Therequest-to-response ratio is therefore r_(r)=½.

[0349] In a third example, the chained pattern of interoperability 4402can be expressed as: task-asynchronous enactment, r_(t)=1, requestwithout response.

[0350] In a fourth example, the nested pattern of interoperability 4416can be expressed as: enactment, task-synchronous (sender),task-asynchronous (receiver), r_(t)=1, request with response,on-own-behalf, r_(r)=1.

[0351] In a fifth example, the parallel-synchronized pattern ofinteroperability 4430 can be expressed as: task-synchronous invocation,r_(t)=1, request with response, on-own-behalf, and r_(r)=1.

[0352] The structures of these interoperability aspects can be modeledby directed graphs, as discussed above in Sections II and III.

[0353]FIG. 45 is a block diagram of a corporate procurement process(CPP). In FIG. 45, it is assumed that a Buyer 4502 wants to buy a numberof different goods. A first supplier 4504 and a second supplier 4506 areavailable to supply the goods, and a first shipper 4508, a secondshipper 4510, and a third shipper 4512 are available to ship the goodsfrom one or both of the suppliers 4504 and 4506 to the buyer 4502.

[0354]FIG. 46 is a block diagram of a collaborative workflow. In FIG.46, the buyer 4502, the first supplier 4504, and the first shipper 4508are interacting to transport a good from the supplier 4504 to the buyer4502.

[0355] In FIG. 46, a user inside the Buyer 4502 queries a marketplacefor goods of their need. Specifically, the user requests a purchase(Purchase Request 4602) through a procurement application that checksthe procurement policies at the Buyer 4502, identifies the supplier 4504and finally approves or disapproves the procurement request (InvoiceApproval 4604). Upon confirmation, an operator approves the actualpurchase order (PO Approval 4606), and the process of procurement begins(Procurement 4608) Next, the supplier 4504 receives the purchase order(Receive PO 4610), checks availability of the ordered good (Check Good'sAvailability 4612), and confirms the purchase order (Confirm PO). Thesupplier 4504 then receives a financial check from the buyer 4502(Financial check 4616), and reviews a current status of the orderinternally (ReviewOrder 4618).

[0356] The supplier 4504 searches for a transportation service in themarketplace (Find Shipper 4620), based on the local availability(time/date/place), the volume and weight of the goods to be transportedand other service parameters. When the Supplier 4504 has found shipper4508, he requests the shipment service and negotiates the shipmentdetails with him (Negotiate Shipment 4622, 2624). In this case, supplierprovides the goods (provide goods 4626), and shipper 4508 picks up thegoods from the supplier's warehouse (Pick-up Goods 4628) and deliversthem to the Buyer (Deliver Goods 4630, Receive Goods 4632).

[0357] At this point, the buyer 4502 reviews the order and pays (Review& Lodge Payment 4634), while the shipper 4508 confirms delivery to thesupplier 4504 (Confirm Delivery 4636). Finally, the supplier 4504receives the payment from the buyer 4502 (Receive Payment 4638),provides payment to the shipper 4508 (Lodge Payment 4640), and theshipper 4508 receives payment (Receive payment 4642).

[0358]FIG. 46 demonstrates how the procurement process of a buyer can beextended to span multiple companies, i.e. buyer 4502, supplier 4504 and4506, shipper 4508, 4510, and 4512. Each of the participants has theirinternal business process that are of different complexity, which meansthat the internal business process of the buyer 4502 is fairly complexto the business process of the shipper 4504 for example. Both the buyer4502 and the suppliers 4504, 4506 need to find services during theexecution of the overall procurement business process; i.e., the buyer4502 needs to find suppliers 4505, 4506, and the suppliers 4504, 4506need to find shippers 4508, 4510, 4512. The buyer 4502 is a serviceconsumer, suppliers 4504, 4506 are service consumers and providers; andshippers 4508, 4510, 4512 are service providers.

[0359] It should be understood that the large number of potentialexceptions to the above-described process implies that collaborativeworkflows should be interactive and flexible. For example, the firstsupplier 4504 may not have a particular good available, and the processmay have to change the supplier and re-check availability. Also, thedelivery of a good may be delayed, so that a new merge location fordelivery that is close to the buyer 4502 may be necessary. As anotherexample, the assembly of the good may be delayed due to a defect inmaterial, so that the buyer 4502 may have to request a change, e.g.another good, changed delivery date, or new delivery address. As a finalexample, transportation of the good may be constrained by delay of truckdue to weather or traffic, or there may be delays because of missingdocuments.

[0360] Table 7 sets forth interoperability aspects of the scenario ofFIG. 45. TABLE 7 Aspects of Interoperability Control FlowBuyer_(Procurement) Enactment, r_(t) = 1, request with response  Supplier_(ReceivePO) asynchronous, on-own-behalf, r_(r) = 1  Supplier_(Check Good's Availability)   Supplier_(ConfirmPO)  Buyer_(Financialcheck) Buyer_(Financialcheck) Invocation, r_(t) = 1,request with   Supplier_(Review Order) delegated response,task-asynchronous   Shipper_(Deliver Goods) (Buyer_(Financial Check)),r_(r) = 1   Buyer_(Recieve Goods) Buyer_(Procurement) Invocation, r_(t)= 1, request with on-own   Supplier_(Review Order) behalf and delegatedresponses, task-   Shipper_(Deliver Goods) asynchronous(Buyer_(Financial Check)),   Buyer_(Receive Goods) r_(r) = 1:2  Shipper_(Confirm Delivery)   Supplier_(Request Payment)  Buyer_(Review&Lodge Payment) Supplier_(Negotiate Shipment) Enactment,r_(t) = 1, task-asynchronous   Shipper_(Negotiate Shipment) withresponse, on-own-behalf r_(t) = 1 Supplier_(Provide Goods) Invocation,r_(t) = 1, task-asynchronous   Shipper_(PickUp Goods) with response,on-own-behalf r_(t) = 1   Shipper_(Confirm Delivery)  Supplier_(Request Payment) Buyer_(Review&Lodge Payment) Enactment,r_(t) = 1, task-asynchronous   Seller_(Receive Payment) without responseSupplier_(Lodge Payment) Enactment, r_(t) = 1, task-asynchronous  Shipper_(Receive Payment) request without response

Section V

[0361] As discussed above, workflows from one or more entities may beabstracted into a set of workflow views (i.e., virtual workflows), andthese workflow views may be implemented, for example, in collaborationwith corresponding workflow views of other entities. With respect to aparticular one of the entities, however, both of the workflow andassociated workflow view may be executed within, or in association with,a workflow engine such as the workflow engine 410 of FIG. 4.

[0362] That is, the workflow engine 410, as discussed above, performsits duties of, for example, ensuring an order and timing of taskexecution for both the (actual) tasks of the workflow and the (virtual)view tasks of the workflow view. More specifically, such an executingworkflow engine supports the concurrent execution of the tasks and viewtasks, while being aware of the dependencies therebetween. Thisawareness is useful in, for example, enabling communication andsynchronization between the tasks and view tasks.

[0363]FIG. 47 is a block diagram of a workflow management system 4702.The workflow management system 4702 is similar in many respects to theworkflow management system 402 of FIG. 4. The workflow management system4702, however, additionally includes an aggregation engine 4704, whichis operable to compile a workflow and its associated workflow view intoan aggregated workflow to be executed by the workflow engine 410.

[0364] Operations of the aggregation engine 4704 are discussed belowwith reference to various figures discussed herein. For example, asdiscussed above, FIG. 2 illustrates a specific example of animplementation of a three-tier workflow model, in which the workflow K206 of the company B 202 is associated with the workflow view L 208 ofthe company 202. The workflow view L 208 is operating in collaborationwith the workflow view P 212 of company A 204 (itself associated withthe workflow O 210 of the company A 204).

[0365] In FIG. 2, the view task “production planning” 218 hides tasks“plan production” 214 and “approval” 216, so that the company A 204 mayonly interact with view task “production planning” 218 (i.e.,interactions between company A 204 and the workflow K 206 areconstrained in this sense). Nonetheless, company A 204 is assured of anawareness of a current state of task(s) “plan production” 214 and task“approval” 216, e.g., that they are being executed. More specifically,as described above with reference to FIGS. 5-7, a correlation between anexecution state of view task “production planning” 218 relative to task“plan production” 214 and task “approval” 216 is maintained through theuse of state dependencies such as those set forth in Table 1, using, forexample, the Petri-Net representations of FIGS. 5-7. Such statedependencies guard against, for example, view task “production planning”218 being in a state “running” while task “plan production”214 isactually in a state “aborted.”

[0366] Although such state dependencies ensure that states of view taskscorrespond to states of associated tasks, they do not necessarily ensurethat a workflow view will be executed in a workflow engine in fullsynchronization with its associated workflow. For example, for theworkflow view L 208 to interact with the workflow view P 212, routingtasks are included within the two workflow views. It is possible thatsuch routing tasks may upset synchronization between the workflow view L208 and its associated workflow K 206.

[0367] For example, the workflow view L 208 includes the routing task“notification” 220 and the routing task “check response” 230, while theworkflow view P includes the routing tasks “response” 228 and “requestto assemble” 258. These tasks 220, 228, 230, and 258 are essentially anAND-split task, an AND-split task, an AND-join task, and an AND-jointask, respectively (as shown in FIG. 3, and discussed in more detailbelow). The tasks 220, 228, 230, and 258 may be added as part of anexpansion operation such as described above in Section III.

[0368] The routing tasks 220 and 230, however, do not have strict statedependencies with an associated task within the workflow K 206. As aresult, the workflow view L 208 and the workflow K 206 may not remainfully synchronized. For example, there is the possibility that, duringexecution of the workflow view L 208 and the workflow K 206, the routingtask “XOR split” 234 may begin before the workflow view (routing) task230 has been completed. In the production processes of FIG. 2, thismalfunction may mean that production of widgets begins (in tasks 236/238or tasks 240/242) before verification of a need for such widgets on thepart of the company A 204 is made. Of course, such a situation couldresult in a meaningful loss of profit and/or wasteful use of resourceswith respect to company B 202.

[0369]FIG. 48 is an illustration of a more generic example of thethree-tiered workflow model of FIG. 2. More specifically, FIG. 47illustrates the various production and routing tasks discussed abovewith respect to the workflows and workflow views of FIG. 2, butrepresents these tasks abstractly. In this regard, FIG. 47 is similar toFIG. 3, which, as explained above with respect to FIG. 3, includes anabstracted version of the workflow K 206, referred to as the workflow K302, as well as an abstracted version of the workflow view L 208,referred to as the workflow view L 304.

[0370] In FIG. 3, the coalition workflow 354 is illustrated whichincorporates any routing tasks added to the workflow view L 304 forcollaborating with the workflow view P 308. However, in FIG. 48, routingtasks 220 and 230 of FIG. 2 are explicitly illustrated in their abstractforms as an AND-split task l4 4802 and an AND-join task l5 4804,respectively. Similarly, routing tasks 228 and 258 are explicitlyillustrated in their abstract forms as an AND split task p4 4806 and anAND-join task p5 4808, respectively.

[0371]FIG. 49 is an illustration of an aggregate workflow 4900. Theaggregate workflow 4900 is designed to ensure that a workflow and itsassociated workflow view are executed in synchronization with oneanother. More specifically, the aggregate workflow 4900 is compiled froma workflow and its associated workflow view by the aggregation engine4704, and is operable to support concurrent execution of the workflowand the workflow view within the workflow engine 410.

[0372] In the aggregate workflow 4900, an aggregating routing task a14902 is included, along with a corresponding aggregating routing task a24904. The aggregating routing tasks a1 4902 and a2 4904 bound theworkflow view task l1 330 and its associated workflow tasks k1 310 andk2 312. As a result, the workflow view task l1 330 may not start beforethe task k1 310, and the aggregate workflow may not proceed beyond theaggregating routing task a2 4904 until both the workflow view task l1330 and the workflow task k2 312 have completed.

[0373] Similarly, an aggregating routing task a3 4906 and an aggregatingrouting task a4 4908 are included which bound the workflow view task l2332, as well as all of its associated workflow tasks k3 314, k4 316, k5318, k6 320, k7 322, and k8 324. Finally, an aggregating routing task a54910 and an associated aggregating routing task a6 4912 are includedwhich bound the workflow view task l3 334 and its associated workflowtasks k9 326 and k10 328.

[0374] Thus, the aggregate workflow 4900 prevents the potential problemdiscussed above, i.e., the possibility that the workflow task k3 314will begin before the routing task 4804 (representing, for example, therouting task 230 of FIG. 2) has ended. This is because, as should beclear from FIG. 49, the routing task l5 4804 and the workflow task k3314 are now arranged with respect to one another in a serial orconsecutive fashion, rather than in a parallel fashion. That is, abeginning of the workflow task k3 314 is strictly dependent upon anending of the routing task l5 4804.

[0375] Moreover, the aggregate workflow 4900 may be easily executed bythe workflow engine 410. That is, the workflow engine 410 need not bemodified to enact the aggregate workflow 4900. As a result, the workflowengine 410 may be considered to be a conventional workflow engine, apartfrom the ability to maintain an awareness of (e.g., state) relationshipsbetween workflow view tasks and their corresponding workflow tasks, asdescribed herein and indicated by, for example, the curved lines shownin FIGS. 2, 3, and 48 (not shown in FIG. 49 for the sake of clarity).

[0376] This awareness on the part of the workflow engine 410 manifests,for example, in actions by the workflow engine associated with:receiving a request to alter a state of a workflow task, altering thestate of the workflow task, and altering a state of a correspondingworkflow view task accordingly (or, conversely, receiving a request toalter a state of a workflow view task, altering the state of theworkflow view task, and altering a state of a corresponding workflowtask accordingly). These actions are similar to, and/or in accordancewith, the rules and actions associated with state changes discussedabove.

[0377]FIG. 50 is a flowchart 5000 illustrating techniques for changing astate of a task within an actual workflow. That is, FIG. 50 correspondsto the situation just described, in which a workflow task receives astate change request and the workflow engine 410 must respondaccordingly.

[0378] In FIG. 50, then, the workflow engine 410 receives a request tochange a state of a workflow task (5002). The workflow engine 410determines whether the request is valid (5004) (as illustrated in FIG.5); if so, then the workflow engine 410 changes the state of theworkflow task (5006). The workflow task then notifies its associatedworkflow view task of the state change (5008).

[0379] The workflow view task then evaluates whether its state shouldchange, in response to the state change of the workflow task (5010).This determination is made by, for example, checking the rules specifiedby Table 1 above (5012). If so, then the workflow view task changes itsstate (5014).

[0380] If the state transition of either the workflow task or theworkflow view task is not legal (5016), then the illegal statetransition is rolled back (5018). Otherwise, the transition is committedand changes are persisted in the workflow engine 410 (5020), and thestatus change request ends (5022). In case of an illegal transition, orif the original state change request was invalid (5004), then the statuschange request also ends (5022). Once the status change request ends,the workflow engine 410 may proceed with execution of the aggregateworkflow 4900.

[0381]FIG. 51 is a flowchart 5100 illustrating techniques for changing astate of a workflow view task within a workflow view. That is, FIG. 51corresponds to the situation described above, in which a workflow viewtask receives a state change request and the workflow engine 410 mustrespond accordingly.

[0382] In FIG. 51, then, the workflow engine 410 receives a request tochange a state of a workflow view task (5102). The workflow engine 410determines whether the request is valid (5104); if so, then the workflowengine 410 changes the state of the workflow view task (5106). Theworkflow view task then notifies its associated workflow task(s) thatare in the state “open” of the state change (5108).

[0383] The workflow task then evaluates whether its state should change,in response to the state change of the workflow view task (5110). Thisdetermination is made by, for example, checking the rules specified byTable 1 above (5112). If so, then the workflow task changes its state(5114).

[0384] If the state transition of either the workflow view task or theworkflow task is not legal (5116), then the illegal state transition isrolled back (5118). Otherwise, the transition is committed and changesare persisted in the workflow engine 410 (5120), and the status changerequest ends (5122). In case of an illegal transition, or if theoriginal state change request was invalid (5104), then the status changerequest also ends (5122). Once the status change request ends (5122),the workflow engine 410 may proceed with execution of the aggregateworkflow 4900.

[0385]FIG. 52 is a flowchart 5200 for aggregating a workflow view and aworkflow into an aggregated workflow. In FIG. 52, a workflow view suchas the workflow view L 304 of FIGS. 3 and 48, including the routingtasks 4802 and 4804 corresponding to the routing tasks 220 and 230 ofthe example workflow view L 208 of FIG. 2, is assigned to a workflow K(302 to form an aggregate workflow such as the aggregate workflow 4900(5202). Next, a first workflow view task “n” within the workflow view isconsidered (5204), e.g., the workflow view task l1 330.

[0386] If the workflow view task n is a routing task (5206), then thenext consecutive workflow view task n+1 is considered (5204). If theworkflow view task is not a routing task (5206), then aggregationrouting tasks are added to the aggregate workflow, bounding the workflowview task n being considered (5208). A more detailed procedure foradding the aggregation routing tasks is discussed below with respect toFIG. 53. Such aggregation routing tasks correspond to, for example, theaggregation routing tasks 4902 and 4904 of FIG. 49, which are anAND-split and an AND-join, respectively.

[0387] Once the aggregation routing tasks have been added with respectto a particular workflow view task n, then workflow task(s)corresponding to the workflow view task n are identified (5210). Forexample, if the workflow view task n corresponds to the workflow viewtask l1 330, then the corresponding workflow tasks are the workflow taskk1 310 and k2 312.

[0388] A dependency is then added from a first one of the aggregationrouting tasks, e.g., from the AND-split 4902, to the identified workflowtask(s) (5212; i.e., to a first one of the identified workflow tasks).In the example of FIG. 49, this operation corresponds to adding thedependency from the AND-split aggregation routing task 4902 to theworkflow task k1 310.

[0389] Similarly, a dependency is then added to a second one of theaggregation routing tasks, e.g., to the AND-join 4904, from theidentified workflow task(s) (5214; i.e., from a last one of theidentified workflow tasks). In the example of FIG. 49, this operationcorresponds to adding the dependency to the AND-join aggregation routingtask 4904 from the workflow task k1 312.

[0390] If the workflow view task n is not the last view task in theworkflow view (5216), then the next consecutive workflow view task n+1is considered (5204). Otherwise, if the workflow view task n is thefinal workflow view task in the workflow view being considered, then theprocess ends.

[0391]FIG. 53 is a flowchart 5300 for inserting aggregation routingtasks into the aggregate workflow of FIG. 52. That is, FIG. 53 describesthe operation of inserting a pair of aggregation routing tasks around aparticular workflow view task (5208) in more detail.

[0392] In FIG. 53, an AND-split (aggregation) routing task is added infront of the workflow view task n (5302). Then, an AND-join(aggregation) routing task is added after the workflow view task n(5304). These routing tasks correspond to, for example, the AND-splitaggregation routing task 4902 and the AND-join aggregation routing task4904 of aggregate workflow 4900.

[0393] Next, dependencies are inserted from the AND-split routing taskto the workflow view task, and from the workflow view task to theAND-join routing task (5306). A previously incoming dependency to theworkflow view task n is re-located to the AND-split routing task (5308).Finally, a previously outgoing dependency from the workflow view task nis re-located to the AND-join routing task (5310). Having inserted theaggregation routing tasks in the manner just described, the operation ofidentifying workflow task(s) corresponding to the workflow view task nmay be commenced (5210 in FIG. 52).

[0394] By performing the operations of FIGS. 52 and 53 for each workflowview task within a workflow view, an aggregate workflow is compiled bythe aggregation engine 4704, so that a workflow and its associatedworkflow view may be concurrently executed within the workflow engine410. Of course, it should be understood that the aggregation engine 4704may be included within, as well as apart from, the workflow engine 410,and is shown as a separate element within FIG. 47 merely for the sake ofillustration.

[0395] By compiling an aggregate workflow in the manner(s) describedabove, a conventional workflow engine may be conveniently and reliablyused as the workflow engine 410, with relatively minor modifications.Operations of the workflow and its corresponding workflow view arereliably maintained, both internally and with respect to one another.Finally, the process(es) for aggregating the workflow and workflow viewinto an aggregate workflow, examples of which are described above, arestraight-forward and are easily and reliably performed by theaggregation engine 4704.

[0396] In conclusion, Section I describes a three-tier workflow modeland architecture, in which a coalition of entities having privateworkflows may together implement collaborative workflows, even when theprivate workflows are heterogeneous in nature and existing before thedesired collaborative workflow. In this model, an intermediate levelreferred to as “workflow views” represent abstracted versions of theprivate workflows, and thereby maintain the confidential nature of theprivate workflows. The workflow views also help maintain synchronizationbetween the private workflows and the collaborative workflow, and allowdifferent “views” of the private workflows to be presented to differentpartners within the coalition.

[0397] Section II describes techniques for altering abstraction levelsof workflows. Such techniques can be used for various purposes, such asmaintaining a privacy level of a workflow while demonstrating theworkflow to outside parties. The techniques may also be used toimplement the three-tier workflow model of Section I, i.e., may be usedto transfer between workflows and workflow views.

[0398] Section III describes techniques for joining multiple workflowsinto a combined workflow, and for decomposing a combined workflow into aplurality of subsets of the workflow, while maintaining a necessaryorder of execution of the workflow(s). These techniques may be usedanytime that two or more entities wish to utilize their respectiveworkflows as part of a collaboration. More particularly, for example,the techniques may be used in the context of the three-tier workflowmodel of Section I, i.e., may be used to combine the workflow views ofvarious companies into a single collaborative workflow.

[0399] Section IV describes examples of situations in whichcollaborative process may be useful, as well as terminology fordescribing collaborative workflows in a useful manner.

[0400] Section V describes techniques for concurrently executingworkflows and their associated workflow views in the context of anaggregate workflow. More specifically, a workflow and its associatedworkflow view are compiled into a single workflow. Tasks of the workflowand workflow view, rather than being executed in parallel, are executedin more of a serial, consecutive fashion within the single, aggregateworkflow. As a result, the aggregate workflow ensures that a workflowview does not proceed faster or slower than its associated workflow,even with respect to routing tasks added to the workflow view that arenot necessarily tied to a corresponding task within the workflow. Inthis way, a workflow engine may easily and reliably execute the workflowand workflow view in synchronization with one another, while stillmaintaining the state dependencies therebetween that are described abovein, for example, Sections I and II.

[0401] A number of implementations have been described. Nevertheless, itwill be understood that various modifications may be made. Accordingly,other implementations are within the scope of the following claims.

What is claimed is:
 1. A method of modifying an abstraction level of aworkflow, the method comprising: analyzing a workflow to determine afirst plurality of tasks; combining the first plurality of tasks into afirst virtual task within an abstracted workflow; and linking the firstvirtual task to the first plurality of tasks such that a virtualexecution of the abstracted workflow corresponds to an actual executionof the workflow.
 2. The method of claim 1 wherein the workflow furthercomprises a second plurality of tasks, and wherein combining the firstplurality of tasks comprises combining the second plurality of tasksinto a second virtual task within the abstracted workflow.
 3. The methodof claim 2 wherein linking the first virtual task to the first pluralityof tasks comprises linking the second virtual task to the secondplurality of tasks such that a virtual execution of the abstractedworkflow corresponds to an actual execution of the workflow.
 4. Themethod of claim 3 wherein analyzing the workflow comprises: determiningthat a last task within the first plurality of tasks precedes at mostone subsequent task within the second plurality of tasks within theworkflow.
 5. The method of claim 4 wherein analyzing the workflowfurther comprises determining that no internal task within the firstplurality of tasks, exclusive of the last task, immediately precedes anexternal task that is not included within the first plurality of tasks.6. The method of claim 4 wherein analyzing the workflow furthercomprises determining that no internal task within the first pluralityof tasks, exclusive of a first task of the first plurality of tasks,immediately succeeds an external task that is not included within thefirst plurality of tasks.
 7. The method of claim 3 wherein analyzing theworkflow comprises determining whether a plurality of conditions aremet, and further wherein determining whether the plurality of conditionsare met comprises: inputting a selected task from the first plurality oftasks, the selected task being a first task of the first plurality oftasks; considering each succeeding task of the selected task until alast task of the first plurality of tasks is reached, wherein the lasttask precedes at most one subsequent task within the second plurality oftasks within the workflow; determining that no internal task within thefirst plurality of tasks, exclusive of the last task, immediatelyprecedes an external task that is not included within the firstplurality of tasks; and determining that no internal task within thefirst plurality of tasks, exclusive of the first task, immediatelysucceeds an external task that is not included within the firstplurality of tasks.
 8. The method of claim 7 further comprising:determining that the plurality of conditions are not met; considering apreceding task outside of the first plurality of tasks and preceding thefirst plurality of tasks within the workflow, the preceding taskimmediately preceding at least a first pair of tasks; determining thatthe last task within the first plurality of tasks is immediatelypreceded by at least a second pair of tasks; and defining a modifiedfirst plurality of tasks comprising the preceding task, the last task,and all intervening tasks.
 9. The method of claim 8 wherein combiningthe first plurality of tasks comprises combining the modified firstplurality of tasks into the first virtual task within the abstractedworkflow.
 10. The method of claim 1 wherein analyzing the workflowcomprises selecting all task subsets of the workflow which, when used asthe first plurality of tasks, allow the linking of the first virtualtask to the first plurality of tasks.
 11. The method of claim 1 whereinanalyzing the workflow comprises: inputting a selected task from amongthe workflow; and determining a first subset of tasks inclusivelypreceding the selected task which, when used as the first plurality oftasks, allow the linking of the first virtual task to the firstplurality of tasks.
 12. The method of claim 11 further comprisingdetermining a second subset of tasks inclusively succeeding the selectedtask which, when used as the first plurality of tasks, allow the linkingof the first virtual task to the first plurality of tasks.
 13. Themethod of claim 1 wherein analyzing the workflow comprises: expressingactual tasks within the first plurality of tasks as first verticeswithin a first matrix, wherein values of the first vertices within thefirst matrix are determined by actual dependencies between the taskswithin the first plurality of tasks, and wherein combining the firstplurality of tasks into a first virtual task further comprisesexpressing virtual tasks within the abstracted workflow as secondvertices within a second matrix, wherein values of the second verticeswithin the second matrix are determined by virtual dependencies betweenthe virtual tasks within the abstracted workflow.
 14. The method ofclaim 13 wherein linking the first virtual task to the first pluralityof tasks comprises replacing a selected plurality of the first verticeswith a selected one of the second vertices.
 15. The method of claim 13wherein linking the first virtual task to the first plurality of taskscomprises replacing a selected one of the second vertices with aselected plurality of the first vertices.
 16. The method of claim 1wherein the first plurality of tasks within the workflow areconfidential tasks associated with a first party, and wherein theabstracted workflow permits communications regarding the confidentialtasks without divulging the confidential nature of the confidentialtasks.
 17. An apparatus comprising a storage medium having instructionsstored thereon, the instructions including: a first code segment forgrouping a task subset from a plurality of tasks comprising a workflow;a second code segment for constructing a virtual workflow including afirst virtual task; and a third code segment for associating the tasksubset with the first virtual task by requiring that completion of thetask subset corresponds to completion of the first virtual task.
 18. Theapparatus of claim 17 wherein the task subset includes confidentialtasks associated with a first party, and wherein the virtual workflowpermits communications regarding the confidential tasks withoutdivulging the confidential nature of the confidential tasks.
 19. Theapparatus of claim 17 wherein the first code segment comprises a fourthcode segment for selecting all task groupings of the workflow which,when used as the task subset, allow the third code segment to associatethe task subset with the first virtual task.
 20. The apparatus of claim17 wherein the first code segment comprises: a fourth code segment forinputting a selected task from among the workflow; and a fifth codesegment for determining a first grouping of tasks inclusively precedingthe selected task which, when used as the task subset, allow the thirdcode segment to associate the first virtual task with the task subset.21. The apparatus of claim 20 further comprising a sixth code segmentfor determining a second grouping of tasks inclusively succeeding theselected task which, when used as the task subset, allow the linking ofthe first virtual task to the task subset.
 22. The apparatus of claim 17wherein the first code segment comprises: a fourth code segment forexpressing actual tasks within the task subset as first vertices withina first matrix, wherein values of the first vertices within the firstmatrix are determined by actual dependencies between the tasks withinthe task subset, and wherein the third code segment further comprises afifth code segment for expressing the first virtual task within thevirtual workflow as second vertices within a second matrix, whereinvalues of the second vertices within the second matrix are determined byvirtual dependencies between the virtual tasks within the virtualworkflow.
 23. The apparatus of claim 22 wherein the third code segmentfurther comprises a sixth code segment for replacing a selectedplurality of the first vertices with a selected one of the secondvertices.
 24. The apparatus of claim 22 wherein the third code segmentfurther comprises a sixth code segment for replacing a selected one ofthe second vertices with a selected plurality of the first vertices. 25.The apparatus of claim 17 wherein the third code segment comprises afourth code segment for ensuring that a final task of the task subsetimmediately precedes no more than one subsequent task of a remainingplurality of tasks within the workflow.
 26. The apparatus of claim 17wherein the third code segment comprises a fourth code segment forensuring that no task of the task subset, other than a final task of thetask subset, immediately precedes an external task that is external tothe task subset and included within the workflow.
 27. The apparatus ofclaim 17 wherein the third code segment comprises a fourth code segmentfor ensuring that no task of the task subset, other than a first task ofthe task subset, immediately succeeds an external task that is externalto the task subset and included within the workflow.
 28. A workflowmodel comprising: a workflow comprising a first task and a second task;a workflow view corresponding to the workflow and comprising a firstvirtual task; a first dependency between a first execution of the firsttask and a virtual execution of the first virtual task; and a seconddependency between a second execution of the second task and the virtualexecution of the first virtual task.
 29. The workflow model of claim 28wherein the first dependency and the second dependency communicateexecution state information about the first and second task,respectively, to the first virtual task.
 30. The workflow model of claim28 wherein the first dependency and the second dependency ensure that anactual completion of the first and second task is reflected as acompletion of the first virtual task.
 31. The workflow model of claim 28wherein the first task is confidential to an owner of the workflow, andfurther wherein the workflow view allows communications between theowner and a second party which protect the confidentiality of the firsttask.
 32. The workflow model of claim 31 wherein the communicationsinclude a collaborative workflow between the owner and the second party,wherein the collaborative workflow includes the workflow view.